Re: Migrating to wicket 1.5
On Thu, Mar 1, 2012 at 8:52 AM, Douglas Ferguson the...@gmail.com wrote:
See below...
On Feb 29, 2012, at 11:49 PM, Dan Retzlaff wrote:
Douglas,
Regarding javascript references: instead of adding a header contributor,
have your component override renderHead(IHeaderResponse response) and use
response.renderJavaScriptReference().
Thanks!
Regarding AbortException: instead of grabbing the servlet response, writing
to it immediately, and throwing AbortException, replace the current request
handler with one that writes the response. See DownloadLink#onClick for an
example. (Ref
http://mail-archives.apache.org/mod_mbox/wicket-users/201105.mbox/%3cbanlktimkstujmwzsd2lhhkbyzcungcq...@mail.gmail.com%3E
)
I was catching it not throwing it. Is there a comparable scenario in 1.5?
Here are some other things I ran into that I don't see in the migration doc
1) RestartResponseAtInterceptPageException
org.apache.wicket.RestartResponseAtInterceptPageException
2) getRequestCycle().setRedirect(false)
This is handled automatically by Wicket, but if you want full control
then you need to use this:
cycle.scheduleRequestHandlerAfterCurrent(new
RenderPageRequestHandler(new PageProvider(..),
RenderPageRequestHandler.RedirectPolicy.NEVER))
3) IRequestTarget is gone
Replaced by IRequestHandler
http://wicketinaction.com/2011/07/wicket-1-5-request-mapper/
http://wicketinaction.com/2011/07/wicket-1-5-mounting-pages/
http://wicketinaction.com/2011/07/wicket-1-5-mounting-resources/
4) AbstractRequestTargetUrlCodingStrategy is goine
The links above should explain this.
5) UploadWebRequest is gone
No need of this anymore. See wicket-examples - upload for a demo
(org.apache.wicket.examples.upload.UploadApplication)
Feel free to update the migration page where you see it misses some info.
Dan
On Wed, Feb 29, 2012 at 9:01 PM, Douglas Ferguson the...@gmail.com wrote:
Just found another one:
What did AbortException get replaced with?
Douglas
On Feb 29, 2012, at 10:44 PM, Douglas Ferguson wrote:
I was reading the migration doc and I'm not sure how I would migrate
this to 1.5:
WebRequest webRequest = (WebRequest)
RequestCycle.get().getRequest();
HttpServletRequest httpServletRequest =
(HttpServletRequest)webRequest.getContainerRequest();
String jqueryURl =
http://ajax.googleapis.com/ajax/libs/jquery/1.4.2/jquery.min.js;;
if(httpServletRequest.isSecure()){
jqueryURl = jqueryURl.replaceFirst(http://;,
https://;);
}
component.add(JavascriptPackageResource.getHeaderContribution(jqueryURl));
-
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
--
Martin Grigorov
jWeekend
Training, Consulting, Development
http://jWeekend.com
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: Migrating to wicket 1.5
Thanks!
I also noticed that hybridurlcodingstrategy is missing.
I did some reading but haven't found a solution that is 100%
Douglas
On Mar 1, 2012, at 2:01 AM, Martin Grigorov wrote:
On Thu, Mar 1, 2012 at 8:52 AM, Douglas Ferguson the...@gmail.com wrote:
See below...
On Feb 29, 2012, at 11:49 PM, Dan Retzlaff wrote:
Douglas,
Regarding javascript references: instead of adding a header contributor,
have your component override renderHead(IHeaderResponse response) and use
response.renderJavaScriptReference().
Thanks!
Regarding AbortException: instead of grabbing the servlet response, writing
to it immediately, and throwing AbortException, replace the current request
handler with one that writes the response. See DownloadLink#onClick for an
example. (Ref
http://mail-archives.apache.org/mod_mbox/wicket-users/201105.mbox/%3cbanlktimkstujmwzsd2lhhkbyzcungcq...@mail.gmail.com%3E
)
I was catching it not throwing it. Is there a comparable scenario in 1.5?
Here are some other things I ran into that I don't see in the migration doc
1) RestartResponseAtInterceptPageException
org.apache.wicket.RestartResponseAtInterceptPageException
2) getRequestCycle().setRedirect(false)
This is handled automatically by Wicket, but if you want full control
then you need to use this:
cycle.scheduleRequestHandlerAfterCurrent(new
RenderPageRequestHandler(new PageProvider(..),
RenderPageRequestHandler.RedirectPolicy.NEVER))
3) IRequestTarget is gone
Replaced by IRequestHandler
http://wicketinaction.com/2011/07/wicket-1-5-request-mapper/
http://wicketinaction.com/2011/07/wicket-1-5-mounting-pages/
http://wicketinaction.com/2011/07/wicket-1-5-mounting-resources/
4) AbstractRequestTargetUrlCodingStrategy is goine
The links above should explain this.
5) UploadWebRequest is gone
No need of this anymore. See wicket-examples - upload for a demo
(org.apache.wicket.examples.upload.UploadApplication)
Feel free to update the migration page where you see it misses some info.
Dan
On Wed, Feb 29, 2012 at 9:01 PM, Douglas Ferguson the...@gmail.com wrote:
Just found another one:
What did AbortException get replaced with?
Douglas
On Feb 29, 2012, at 10:44 PM, Douglas Ferguson wrote:
I was reading the migration doc and I'm not sure how I would migrate
this to 1.5:
WebRequest webRequest = (WebRequest)
RequestCycle.get().getRequest();
HttpServletRequest httpServletRequest =
(HttpServletRequest)webRequest.getContainerRequest();
String jqueryURl =
http://ajax.googleapis.com/ajax/libs/jquery/1.4.2/jquery.min.js;;
if(httpServletRequest.isSecure()){
jqueryURl = jqueryURl.replaceFirst(http://;,
https://;);
}
component.add(JavascriptPackageResource.getHeaderContribution(jqueryURl));
-
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
--
Martin Grigorov
jWeekend
Training, Consulting, Development
http://jWeekend.com
-
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: Migrating to wicket 1.5
Feel free to update the migration page where you see it misses some info.
What's the process for updating?
Dan
On Wed, Feb 29, 2012 at 9:01 PM, Douglas Ferguson the...@gmail.com wrote:
Just found another one:
What did AbortException get replaced with?
Douglas
On Feb 29, 2012, at 10:44 PM, Douglas Ferguson wrote:
I was reading the migration doc and I'm not sure how I would migrate
this to 1.5:
WebRequest webRequest = (WebRequest)
RequestCycle.get().getRequest();
HttpServletRequest httpServletRequest =
(HttpServletRequest)webRequest.getContainerRequest();
String jqueryURl =
http://ajax.googleapis.com/ajax/libs/jquery/1.4.2/jquery.min.js;;
if(httpServletRequest.isSecure()){
jqueryURl = jqueryURl.replaceFirst(http://;,
https://;);
}
component.add(JavascriptPackageResource.getHeaderContribution(jqueryURl));
-
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
--
Martin Grigorov
jWeekend
Training, Consulting, Development
http://jWeekend.com
-
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: Cache TextTemplateResourceReferences
Hi,
I see this is problematic indeed...
Here is how you can achieve this:
class MyPackageTTRR extends TextTemplateResourceReference {
@Override
public IResource getResource() {
ResourceStreamResource resource = (ResourceStreamResource) resource;
resource.setCacheDuration(Duration.xyz);
return resource;
}
}
On Wed, Feb 29, 2012 at 7:52 PM, exaptis david.loid...@gmail.com wrote:
Hi,
i've been following this post in order to generate dynamic JS/CSS files (
https://cwiki.apache.org/WICKET/dynamically-generate-a-css-stylesheet.html
https://cwiki.apache.org/WICKET/dynamically-generate-a-css-stylesheet.html
).
Now I'm expiring white page flickers on page changes inside the browser,
due to the fact that TextTemplateResourceReferences are not versioned
(filename-ver-timestamp.ext) or sent with Cache-Headers (per default
they are delivered with Cache: no-cache). As soon as we have uncached CSS or
JS files FF/IE/Chrome/Safari seem to reload the whole page instead of
applying the cached files and this leads to these annoying page flickers.
So i'm searching for a solution to be able to cache
TextTemplateResourceReferences by enabling the version and setting the cache
headers, but I haven't found a solution yet.
I'm using Wicket 1.5.3.
From a friend of mine I got the tip to check IStaticCacheableResources and
subclass TextTemplateResourceReference in order to return
IStaticCacheableResources, but I didn't have the time yet to test it out.
http://www.jarvana.com/jarvana/view/org/apache/wicket/wicket-core/1.5.0/wicket-core-1.5.0-javadoc.jar!/org/apache/wicket/request/resource/caching/IStaticCacheableResource.html
http://www.jarvana.com/jarvana/view/org/apache/wicket/wicket-core/1.5.0/wicket-core-1.5.0-javadoc.jar!/org/apache/wicket/request/resource/caching/IStaticCacheableResource.html
Any help on this would be really great, as I'm quite new to wicket and
haven't found a good tutorial yet which explains how caching for resources
is properly applied.
--
View this message in context:
http://apache-wicket.1842946.n4.nabble.com/Cache-TextTemplateResourceReferences-tp4432342p4432342.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
--
Martin Grigorov
jWeekend
Training, Consulting, Development
http://jWeekend.com
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: Multi Tab and Session
Hi Martin,
I compile the wicket project via Maven from the command line. I do not use the
IDE to start the project and trace it? Do you have a hint how I can do that? As
IDE, Ia m using IntelliJ IDEA.
Andre
Original-Nachricht
Datum: Thu, 1 Mar 2012 09:40:30 +0200
Von: Martin Grigorov mgrigo...@apache.org
An: users@wicket.apache.org
Betreff: Re: Multi Tab and Session
2012/2/29 Andre Schütz andre-p...@gmx.de:
Hi,
I could identify the cause of the problem, but still have no
solution.
I set some breakpoints and made some output messages to trace
the system. The following thinks happened:
(1)
I submit a search in Tab1. The search word will be passed as
Page Parameter to Page2 in Tab1. While Tab1 is showing the loading
animation with it AjaxSelfUpdatingTimerBehavior, I submit a second
search in Tab2. Tab2 switches to its Page2 and the loading animation
stops in both Tabs.
Reason:
-- The constructors of Page2 is called twice on the two Tabs.
As diagram:
01.) Tab1: Page1 submit search
02.) Tab1: Page2 (Page id = 14) calls its constructor and adds a PanelA
03.) Tab1: shows loading animation with its
AjaxSelfUpdatingTimerBehavior at PanelA
04.) Tab2: Page1 submit search
05.) Tab2: Page2 (Page id = 16) calls its constructor and adds a PanelA
06.) Tab2: shows loading animation with its
AjaxSelfUpdatingTimerBehavior at PanelA
07.) Tab1: Page2 (Page id = 17) calls its constructor
08.) Tab1: does not update anymore
09.) Tab2: Page2 (Page id = 18) calls its constructor
10.) Tab2: does not update anymore
I do nothing from the beginning of step 7 and do not know why the
constructor
is called again.
Put a breakpoint in Page2 constructor and see why it is called.
(2)
The same odd behavior happens, when I do the following. I submit a
search
in Tab1 from its Page1. While the loading animation is shown, I reload
the
Page1 in Tab2. The constructor of Page2 in Tab1 is called again and the
Page2 in Tab1 stops its update progress.
As diagram:
01.) Tab1: Page1 submit search
02.) Tab1: Page2 (Page id = 22) calls its constructor and adds a PanelA
03.) Tab1: shows loading animation with its
AjaxSelfUpdatingTimerBehavior at PanelA
04.) Tab2: Reload any Page
05.) Tab1: Page2 (Page id = 23) calls its constructor
06.) Tab1: does not update anymore
I really can't explain to myself, why the constructor is called again.
But I think
that this second call in the individual Tabs is crashing my application.
Any ideas about this odd behavior?
Thank in advance,
Andre
On Wed, 29 Feb 2012 10:10:37 -0800
Dan Retzlaff dretzl...@gmail.com wrote:
Your description is clear, thank you. I'm not certain that the
background
thread's reference to the Session is valid outside of the servlet
request.
I would verify your assumption by logging the session's object ID when
the
value is read/written.
I have one other thought for you. I believe Wicket keeps the most
recent
page in a deserialized state to save itself the work of deserialization
in
the common case of it being required by the next request. (I think the
logic is in PageStoreManager, but it's not clear to me. Hopefully a dev
can
confirm/correct me.) At any rate, this may cause the difference between
your two scenarios. In your successful, single-tab scenario, you may be
benefiting from a lack of serialization/deserialization round-trip. We
have
noticed this difference when our components have transient variables
that
aren't set to null in detach(): in the most recent page the variable
remains not-null; if the session has intermediate requests for other
pages,
the variable is null when next accessed.
Good luck,
Dan
2012/2/29 André Schütz andre-p...@gmx.de
Hi,
Page1 gets the click of the submit button and collects the search
word.
This will be changed into a hash value and set as PageParameter
(q=Hashvalue) to the ResponsePage which is Page2.
Additionally, I store the hash value into a session HashMap which
holds
the hash value as key and an own class with the original search word.
This
class will be filled with the results from the search of the
background
thread.
On Page2, I have the PageParameter as hash value and can search for
the
correct entry of the HashMap in the session to react, when the
results are
found.
I hope, I could describe it.
Andre
Original-Nachricht
Datum: Tue, 28 Feb 2012 14:27:35 -0800
Von: Dan Retzlaff dretzl...@gmail.com
An: users@wicket.apache.org
Betreff: Re: Multi Tab and Session
Hi Andre. I'm trying to understand your setup. A quickstart may be
required.
What does your Page1's onSubmit() look like? Specifically I'd like
to
know
how Page2 knows to watch for word2.
2012/2/28 Andre Schütz andre-p...@gmx.de
Hello,
I have a
Re: Migrating to wicket 1.5
On Thu, Mar 1, 2012 at 10:05 AM, Douglas Ferguson the...@gmail.com wrote:
Thanks!
I also noticed that hybridurlcodingstrategy is missing.
I did some reading but haven't found a solution that is 100%
The default mounting works as HybridUCS - WebApplication#mountPage(),
this uses MountedMapper behind the scenes.
What functionality is missing ?
Douglas
On Mar 1, 2012, at 2:01 AM, Martin Grigorov wrote:
On Thu, Mar 1, 2012 at 8:52 AM, Douglas Ferguson the...@gmail.com wrote:
See below...
On Feb 29, 2012, at 11:49 PM, Dan Retzlaff wrote:
Douglas,
Regarding javascript references: instead of adding a header contributor,
have your component override renderHead(IHeaderResponse response) and use
response.renderJavaScriptReference().
Thanks!
Regarding AbortException: instead of grabbing the servlet response, writing
to it immediately, and throwing AbortException, replace the current request
handler with one that writes the response. See DownloadLink#onClick for an
example. (Ref
http://mail-archives.apache.org/mod_mbox/wicket-users/201105.mbox/%3cbanlktimkstujmwzsd2lhhkbyzcungcq...@mail.gmail.com%3E
)
I was catching it not throwing it. Is there a comparable scenario in 1.5?
Here are some other things I ran into that I don't see in the migration doc
1) RestartResponseAtInterceptPageException
org.apache.wicket.RestartResponseAtInterceptPageException
2) getRequestCycle().setRedirect(false)
This is handled automatically by Wicket, but if you want full control
then you need to use this:
cycle.scheduleRequestHandlerAfterCurrent(new
RenderPageRequestHandler(new PageProvider(..),
RenderPageRequestHandler.RedirectPolicy.NEVER))
3) IRequestTarget is gone
Replaced by IRequestHandler
http://wicketinaction.com/2011/07/wicket-1-5-request-mapper/
http://wicketinaction.com/2011/07/wicket-1-5-mounting-pages/
http://wicketinaction.com/2011/07/wicket-1-5-mounting-resources/
4) AbstractRequestTargetUrlCodingStrategy is goine
The links above should explain this.
5) UploadWebRequest is gone
No need of this anymore. See wicket-examples - upload for a demo
(org.apache.wicket.examples.upload.UploadApplication)
Feel free to update the migration page where you see it misses some info.
Dan
On Wed, Feb 29, 2012 at 9:01 PM, Douglas Ferguson the...@gmail.com wrote:
Just found another one:
What did AbortException get replaced with?
Douglas
On Feb 29, 2012, at 10:44 PM, Douglas Ferguson wrote:
I was reading the migration doc and I'm not sure how I would migrate
this to 1.5:
WebRequest webRequest = (WebRequest)
RequestCycle.get().getRequest();
HttpServletRequest httpServletRequest =
(HttpServletRequest)webRequest.getContainerRequest();
String jqueryURl =
http://ajax.googleapis.com/ajax/libs/jquery/1.4.2/jquery.min.js;;
if(httpServletRequest.isSecure()){
jqueryURl = jqueryURl.replaceFirst(http://;,
https://;);
}
component.add(JavascriptPackageResource.getHeaderContribution(jqueryURl));
-
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
--
Martin Grigorov
jWeekend
Training, Consulting, Development
http://jWeekend.com
-
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
--
Martin Grigorov
jWeekend
Training, Consulting, Development
http://jWeekend.com
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: Migrating to wicket 1.5
On Thu, Mar 1, 2012 at 10:06 AM, Douglas Ferguson the...@gmail.com wrote:
Feel free to update the migration page where you see it misses some info.
What's the process for updating?
Create an account for the Wiki and update the page(s).
Dan
On Wed, Feb 29, 2012 at 9:01 PM, Douglas Ferguson the...@gmail.com wrote:
Just found another one:
What did AbortException get replaced with?
Douglas
On Feb 29, 2012, at 10:44 PM, Douglas Ferguson wrote:
I was reading the migration doc and I'm not sure how I would migrate
this to 1.5:
WebRequest webRequest = (WebRequest)
RequestCycle.get().getRequest();
HttpServletRequest httpServletRequest =
(HttpServletRequest)webRequest.getContainerRequest();
String jqueryURl =
http://ajax.googleapis.com/ajax/libs/jquery/1.4.2/jquery.min.js;;
if(httpServletRequest.isSecure()){
jqueryURl = jqueryURl.replaceFirst(http://;,
https://;);
}
component.add(JavascriptPackageResource.getHeaderContribution(jqueryURl));
-
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
--
Martin Grigorov
jWeekend
Training, Consulting, Development
http://jWeekend.com
-
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
--
Martin Grigorov
jWeekend
Training, Consulting, Development
http://jWeekend.com
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: Multi Tab and Session
Hi, I will check, which page ID is in the request and test your quickstart, when I am back home this evening. Thanks for the advice. I will share my results after the tests. Andre Original-Nachricht Datum: Wed, 29 Feb 2012 20:46:22 -0800 Von: Dan Retzlaff dretzl...@gmail.com An: users@wicket.apache.org Betreff: Re: Multi Tab and Session I reproduced part of your setup with the attached quickstart whose homepage updates a single label with an AjaxSelfUpdatingTimerBehavior. Reloading a page in a second tab (including its version number in the URL) causes subsequent requests to the first tab to be considered stale based on a page render count. This stops the AJAX updates. So Andre, when you load Page1 in Tab2, does your request include the page ID from Tab1? If this isn't the case, then please share a quickstart of your own. Despite your detailed description I'm not sure I'm reproducing your steps exactly. Regarding multiple constructor calls, are you using Chrome 17 or greater? It introduces some funky prerendering business that can cause multiple requests/constructions when you'd otherwise expect one. I just learned this today. Typing localhost:8080 into address bar is enough to make the request, even without hitting enter. Hitting enter causes another request to be made, but it appears it is the first response that is rendered (based on the page ID in the URL). Interesting. http://code.google.com/chrome/whitepapers/prerender.html Dan 2012/2/29 Andre Schütz andre-p...@gmx.de Hi, I could identify the cause of the problem, but still have no solution. I set some breakpoints and made some output messages to trace the system. The following thinks happened: (1) I submit a search in Tab1. The search word will be passed as Page Parameter to Page2 in Tab1. While Tab1 is showing the loading animation with it AjaxSelfUpdatingTimerBehavior, I submit a second search in Tab2. Tab2 switches to its Page2 and the loading animation stops in both Tabs. Reason: -- The constructors of Page2 is called twice on the two Tabs. As diagram: 01.) Tab1: Page1 submit search 02.) Tab1: Page2 (Page id = 14) calls its constructor and adds a PanelA 03.) Tab1: shows loading animation with its AjaxSelfUpdatingTimerBehavior at PanelA 04.) Tab2: Page1 submit search 05.) Tab2: Page2 (Page id = 16) calls its constructor and adds a PanelA 06.) Tab2: shows loading animation with its AjaxSelfUpdatingTimerBehavior at PanelA 07.) Tab1: Page2 (Page id = 17) calls its constructor 08.) Tab1: does not update anymore 09.) Tab2: Page2 (Page id = 18) calls its constructor 10.) Tab2: does not update anymore I do nothing from the beginning of step 7 and do not know why the constructor is called again. (2) The same odd behavior happens, when I do the following. I submit a search in Tab1 from its Page1. While the loading animation is shown, I reload the Page1 in Tab2. The constructor of Page2 in Tab1 is called again and the Page2 in Tab1 stops its update progress. As diagram: 01.) Tab1: Page1 submit search 02.) Tab1: Page2 (Page id = 22) calls its constructor and adds a PanelA 03.) Tab1: shows loading animation with its AjaxSelfUpdatingTimerBehavior at PanelA 04.) Tab2: Reload any Page 05.) Tab1: Page2 (Page id = 23) calls its constructor 06.) Tab1: does not update anymore I really can't explain to myself, why the constructor is called again. But I think that this second call in the individual Tabs is crashing my application. Any ideas about this odd behavior? Thank in advance, Andre On Wed, 29 Feb 2012 10:10:37 -0800 Dan Retzlaff dretzl...@gmail.com wrote: Your description is clear, thank you. I'm not certain that the background thread's reference to the Session is valid outside of the servlet request. I would verify your assumption by logging the session's object ID when the value is read/written. I have one other thought for you. I believe Wicket keeps the most recent page in a deserialized state to save itself the work of deserialization in the common case of it being required by the next request. (I think the logic is in PageStoreManager, but it's not clear to me. Hopefully a dev can confirm/correct me.) At any rate, this may cause the difference between your two scenarios. In your successful, single-tab scenario, you may be benefiting from a lack of serialization/deserialization round-trip. We have noticed this difference when our components have transient variables that aren't set to null in detach(): in the most recent page the variable remains not-null; if the session has intermediate requests for other pages, the variable is null when next accessed. Good luck, Dan 2012/2/29 André Schütz andre-p...@gmx.de Hi, Page1 gets the click of the submit button and collects the
Re: Multi Tab and Session
Use mvnDebug instead of mvn at the command line. This will start it in
debug mode and you can attach to it from IDEA.
Otherwise Wicket quickstart comes with src/test/java/**/Start.java.
Run this class as normal Java application with main(String[]). From
the context menu in the .java file choose Debug 'Start.main()'
2012/3/1 André Schütz andre-p...@gmx.de:
Hi Martin,
I compile the wicket project via Maven from the command line. I do not use
the IDE to start the project and trace it? Do you have a hint how I can do
that? As IDE, Ia m using IntelliJ IDEA.
Andre
Original-Nachricht
Datum: Thu, 1 Mar 2012 09:40:30 +0200
Von: Martin Grigorov mgrigo...@apache.org
An: users@wicket.apache.org
Betreff: Re: Multi Tab and Session
2012/2/29 Andre Schütz andre-p...@gmx.de:
Hi,
I could identify the cause of the problem, but still have no
solution.
I set some breakpoints and made some output messages to trace
the system. The following thinks happened:
(1)
I submit a search in Tab1. The search word will be passed as
Page Parameter to Page2 in Tab1. While Tab1 is showing the loading
animation with it AjaxSelfUpdatingTimerBehavior, I submit a second
search in Tab2. Tab2 switches to its Page2 and the loading animation
stops in both Tabs.
Reason:
-- The constructors of Page2 is called twice on the two Tabs.
As diagram:
01.) Tab1: Page1 submit search
02.) Tab1: Page2 (Page id = 14) calls its constructor and adds a PanelA
03.) Tab1: shows loading animation with its
AjaxSelfUpdatingTimerBehavior at PanelA
04.) Tab2: Page1 submit search
05.) Tab2: Page2 (Page id = 16) calls its constructor and adds a PanelA
06.) Tab2: shows loading animation with its
AjaxSelfUpdatingTimerBehavior at PanelA
07.) Tab1: Page2 (Page id = 17) calls its constructor
08.) Tab1: does not update anymore
09.) Tab2: Page2 (Page id = 18) calls its constructor
10.) Tab2: does not update anymore
I do nothing from the beginning of step 7 and do not know why the
constructor
is called again.
Put a breakpoint in Page2 constructor and see why it is called.
(2)
The same odd behavior happens, when I do the following. I submit a
search
in Tab1 from its Page1. While the loading animation is shown, I reload
the
Page1 in Tab2. The constructor of Page2 in Tab1 is called again and the
Page2 in Tab1 stops its update progress.
As diagram:
01.) Tab1: Page1 submit search
02.) Tab1: Page2 (Page id = 22) calls its constructor and adds a PanelA
03.) Tab1: shows loading animation with its
AjaxSelfUpdatingTimerBehavior at PanelA
04.) Tab2: Reload any Page
05.) Tab1: Page2 (Page id = 23) calls its constructor
06.) Tab1: does not update anymore
I really can't explain to myself, why the constructor is called again.
But I think
that this second call in the individual Tabs is crashing my application.
Any ideas about this odd behavior?
Thank in advance,
Andre
On Wed, 29 Feb 2012 10:10:37 -0800
Dan Retzlaff dretzl...@gmail.com wrote:
Your description is clear, thank you. I'm not certain that the
background
thread's reference to the Session is valid outside of the servlet
request.
I would verify your assumption by logging the session's object ID when
the
value is read/written.
I have one other thought for you. I believe Wicket keeps the most
recent
page in a deserialized state to save itself the work of deserialization
in
the common case of it being required by the next request. (I think the
logic is in PageStoreManager, but it's not clear to me. Hopefully a dev
can
confirm/correct me.) At any rate, this may cause the difference between
your two scenarios. In your successful, single-tab scenario, you may be
benefiting from a lack of serialization/deserialization round-trip. We
have
noticed this difference when our components have transient variables
that
aren't set to null in detach(): in the most recent page the variable
remains not-null; if the session has intermediate requests for other
pages,
the variable is null when next accessed.
Good luck,
Dan
2012/2/29 André Schütz andre-p...@gmx.de
Hi,
Page1 gets the click of the submit button and collects the search
word.
This will be changed into a hash value and set as PageParameter
(q=Hashvalue) to the ResponsePage which is Page2.
Additionally, I store the hash value into a session HashMap which
holds
the hash value as key and an own class with the original search word.
This
class will be filled with the results from the search of the
background
thread.
On Page2, I have the PageParameter as hash value and can search for
the
correct entry of the HashMap in the session to react, when the
results are
found.
I hope, I could describe it.
Andre
Original-Nachricht
Datum: Tue, 28 Feb 2012 14:27:35 -0800
Von: Dan Retzlaff dretzl...@gmail.com
An:
Re: Migrating to wicket 1.5
If I mount a page to the url page1
Then hit page1/foo/bar/abc/xyz
Then in my code i say pageParameters.get(foo) it returns null.
In 1.4 it would return bar
Douglas
On Mar 1, 2012, at 2:09 AM, Martin Grigorov wrote:
On Thu, Mar 1, 2012 at 10:05 AM, Douglas Ferguson the...@gmail.com wrote:
Thanks!
I also noticed that hybridurlcodingstrategy is missing.
I did some reading but haven't found a solution that is 100%
The default mounting works as HybridUCS - WebApplication#mountPage(),
this uses MountedMapper behind the scenes.
What functionality is missing ?
Douglas
On Mar 1, 2012, at 2:01 AM, Martin Grigorov wrote:
On Thu, Mar 1, 2012 at 8:52 AM, Douglas Ferguson the...@gmail.com wrote:
See below...
On Feb 29, 2012, at 11:49 PM, Dan Retzlaff wrote:
Douglas,
Regarding javascript references: instead of adding a header contributor,
have your component override renderHead(IHeaderResponse response) and use
response.renderJavaScriptReference().
Thanks!
Regarding AbortException: instead of grabbing the servlet response,
writing
to it immediately, and throwing AbortException, replace the current
request
handler with one that writes the response. See DownloadLink#onClick for an
example. (Ref
http://mail-archives.apache.org/mod_mbox/wicket-users/201105.mbox/%3cbanlktimkstujmwzsd2lhhkbyzcungcq...@mail.gmail.com%3E
)
I was catching it not throwing it. Is there a comparable scenario in 1.5?
Here are some other things I ran into that I don't see in the migration doc
1) RestartResponseAtInterceptPageException
org.apache.wicket.RestartResponseAtInterceptPageException
2) getRequestCycle().setRedirect(false)
This is handled automatically by Wicket, but if you want full control
then you need to use this:
cycle.scheduleRequestHandlerAfterCurrent(new
RenderPageRequestHandler(new PageProvider(..),
RenderPageRequestHandler.RedirectPolicy.NEVER))
3) IRequestTarget is gone
Replaced by IRequestHandler
http://wicketinaction.com/2011/07/wicket-1-5-request-mapper/
http://wicketinaction.com/2011/07/wicket-1-5-mounting-pages/
http://wicketinaction.com/2011/07/wicket-1-5-mounting-resources/
4) AbstractRequestTargetUrlCodingStrategy is goine
The links above should explain this.
5) UploadWebRequest is gone
No need of this anymore. See wicket-examples - upload for a demo
(org.apache.wicket.examples.upload.UploadApplication)
Feel free to update the migration page where you see it misses some info.
Dan
On Wed, Feb 29, 2012 at 9:01 PM, Douglas Ferguson the...@gmail.com
wrote:
Just found another one:
What did AbortException get replaced with?
Douglas
On Feb 29, 2012, at 10:44 PM, Douglas Ferguson wrote:
I was reading the migration doc and I'm not sure how I would migrate
this to 1.5:
WebRequest webRequest = (WebRequest)
RequestCycle.get().getRequest();
HttpServletRequest httpServletRequest =
(HttpServletRequest)webRequest.getContainerRequest();
String jqueryURl =
http://ajax.googleapis.com/ajax/libs/jquery/1.4.2/jquery.min.js;;
if(httpServletRequest.isSecure()){
jqueryURl = jqueryURl.replaceFirst(http://;,
https://;);
}
component.add(JavascriptPackageResource.getHeaderContribution(jqueryURl));
-
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
--
Martin Grigorov
jWeekend
Training, Consulting, Development
http://jWeekend.com
-
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
--
Martin Grigorov
jWeekend
Training, Consulting, Development
http://jWeekend.com
-
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: Migrating to wicket 1.5
See org.apache.wicket.request.mapper.parameter.UrlPathPageParametersEncoder
With the default encoder these are available as indexed parameters:
pp.get(1) will return 'bar'
On Thu, Mar 1, 2012 at 10:22 AM, Douglas Ferguson the...@gmail.com wrote:
If I mount a page to the url page1
Then hit page1/foo/bar/abc/xyz
Then in my code i say pageParameters.get(foo) it returns null.
In 1.4 it would return bar
Douglas
On Mar 1, 2012, at 2:09 AM, Martin Grigorov wrote:
On Thu, Mar 1, 2012 at 10:05 AM, Douglas Ferguson the...@gmail.com wrote:
Thanks!
I also noticed that hybridurlcodingstrategy is missing.
I did some reading but haven't found a solution that is 100%
The default mounting works as HybridUCS - WebApplication#mountPage(),
this uses MountedMapper behind the scenes.
What functionality is missing ?
Douglas
On Mar 1, 2012, at 2:01 AM, Martin Grigorov wrote:
On Thu, Mar 1, 2012 at 8:52 AM, Douglas Ferguson the...@gmail.com wrote:
See below...
On Feb 29, 2012, at 11:49 PM, Dan Retzlaff wrote:
Douglas,
Regarding javascript references: instead of adding a header contributor,
have your component override renderHead(IHeaderResponse response) and use
response.renderJavaScriptReference().
Thanks!
Regarding AbortException: instead of grabbing the servlet response,
writing
to it immediately, and throwing AbortException, replace the current
request
handler with one that writes the response. See DownloadLink#onClick for
an
example. (Ref
http://mail-archives.apache.org/mod_mbox/wicket-users/201105.mbox/%3cbanlktimkstujmwzsd2lhhkbyzcungcq...@mail.gmail.com%3E
)
I was catching it not throwing it. Is there a comparable scenario in 1.5?
Here are some other things I ran into that I don't see in the migration
doc
1) RestartResponseAtInterceptPageException
org.apache.wicket.RestartResponseAtInterceptPageException
2) getRequestCycle().setRedirect(false)
This is handled automatically by Wicket, but if you want full control
then you need to use this:
cycle.scheduleRequestHandlerAfterCurrent(new
RenderPageRequestHandler(new PageProvider(..),
RenderPageRequestHandler.RedirectPolicy.NEVER))
3) IRequestTarget is gone
Replaced by IRequestHandler
http://wicketinaction.com/2011/07/wicket-1-5-request-mapper/
http://wicketinaction.com/2011/07/wicket-1-5-mounting-pages/
http://wicketinaction.com/2011/07/wicket-1-5-mounting-resources/
4) AbstractRequestTargetUrlCodingStrategy is goine
The links above should explain this.
5) UploadWebRequest is gone
No need of this anymore. See wicket-examples - upload for a demo
(org.apache.wicket.examples.upload.UploadApplication)
Feel free to update the migration page where you see it misses some info.
Dan
On Wed, Feb 29, 2012 at 9:01 PM, Douglas Ferguson the...@gmail.com
wrote:
Just found another one:
What did AbortException get replaced with?
Douglas
On Feb 29, 2012, at 10:44 PM, Douglas Ferguson wrote:
I was reading the migration doc and I'm not sure how I would migrate
this to 1.5:
WebRequest webRequest = (WebRequest)
RequestCycle.get().getRequest();
HttpServletRequest httpServletRequest =
(HttpServletRequest)webRequest.getContainerRequest();
String jqueryURl =
http://ajax.googleapis.com/ajax/libs/jquery/1.4.2/jquery.min.js;;
if(httpServletRequest.isSecure()){
jqueryURl = jqueryURl.replaceFirst(http://;,
https://;);
}
component.add(JavascriptPackageResource.getHeaderContribution(jqueryURl));
-
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
--
Martin Grigorov
jWeekend
Training, Consulting, Development
http://jWeekend.com
-
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
--
Martin Grigorov
jWeekend
Training, Consulting, Development
http://jWeekend.com
-
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
--
Martin Grigorov
jWeekend
Training, Consulting, Development
Re: Migrating to wicket 1.5
Just a quick hint about the code-snipet above. You don't really need to replace the protocol. Change it to this and the browser will automatically use the protocol, that is used by the site embedding the javascript. String jqueryURl = //ajax.googleapis.com/ajax/libs/jquery/1.4.2/jquery.min.js; component.add(JavascriptPackageResource.getHeaderContribution(jqueryURl)); :-) -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Wicket-jQuery-Validator-integration-tp4390885p4434452.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
How to skip a page on back button
Hi All, Is there any way to skip a page using back button. i.e. Forward sequence: HomePage-Page1-Page2 *using browser back button* Current Reverse sequence: Page2-Page1-HomePage Desired Reverse sequence: *Page2-HomePage* I've tried this.getPageMap().remove(this); in Page1 constructor, but it is not working. Any idea..? I'm using Wicket 1.4.19 Thanks -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/How-to-skip-a-page-on-back-button-tp4434470p4434470.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: How to skip a page on back button
Is there any way to skip a page using back button. i.e.
Forward sequence: HomePage-Page1-Page2
If the link from Page1 to Page2 is a Javascript link that does a
location.replace('url for Page2') the browser should not remember Page1 in the
history, if memory serves. Removing from the PageMap is probably something you
need to handle as a consequence of the link though.
- Tor Iver
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
http/https in wicket 1.5
In 1.4 I had ao code up some interesting work arounds to get my app to redirect between http and https based on which page you are requesting. I remember at the time Igor told me that it would be much easer in 1.5. Can anybody point me in the redirection? I'm considering 2 schemes. 1) Running the entire app over ssl (then I just need to detect http and redirect to https) 2) Keep it as is, Only have the login, signup and payment screens be https and then redirect to http. Regardless I'll need to detect http/https and then redirect if necessary. Would this still be done in the AuthorizationStrategy? I've noticed that RequestCycle has changed, and many methods I used are gone. I.E. I used to use requestCycle.getPageParameters() to get the parameters do that I when I redirected to login I would retain the params, so after logging in the user could be sent to their original page. Douglas - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Cache TextTemplateResourceReferences
just one little addition...
instead of
response.setCacheDuration
use
response.enableCaching(Duration., WebResponse.CacheScope.)
Am 01.03.2012 um 09:08 schrieb Martin Grigorov:
Hi,
I see this is problematic indeed...
Here is how you can achieve this:
class MyPackageTTRR extends TextTemplateResourceReference {
@Override
public IResource getResource() {
ResourceStreamResource resource = (ResourceStreamResource) resource;
resource.setCacheDuration(Duration.xyz);
return resource;
}
}
On Wed, Feb 29, 2012 at 7:52 PM, exaptis david.loid...@gmail.com wrote:
Hi,
i've been following this post in order to generate dynamic JS/CSS files (
https://cwiki.apache.org/WICKET/dynamically-generate-a-css-stylesheet.html
https://cwiki.apache.org/WICKET/dynamically-generate-a-css-stylesheet.html
).
Now I'm expiring white page flickers on page changes inside the browser,
due to the fact that TextTemplateResourceReferences are not versioned
(filename-ver-timestamp.ext) or sent with Cache-Headers (per default
they are delivered with Cache: no-cache). As soon as we have uncached CSS or
JS files FF/IE/Chrome/Safari seem to reload the whole page instead of
applying the cached files and this leads to these annoying page flickers.
So i'm searching for a solution to be able to cache
TextTemplateResourceReferences by enabling the version and setting the cache
headers, but I haven't found a solution yet.
I'm using Wicket 1.5.3.
From a friend of mine I got the tip to check IStaticCacheableResources and
subclass TextTemplateResourceReference in order to return
IStaticCacheableResources, but I didn't have the time yet to test it out.
http://www.jarvana.com/jarvana/view/org/apache/wicket/wicket-core/1.5.0/wicket-core-1.5.0-javadoc.jar!/org/apache/wicket/request/resource/caching/IStaticCacheableResource.html
http://www.jarvana.com/jarvana/view/org/apache/wicket/wicket-core/1.5.0/wicket-core-1.5.0-javadoc.jar!/org/apache/wicket/request/resource/caching/IStaticCacheableResource.html
Any help on this would be really great, as I'm quite new to wicket and
haven't found a good tutorial yet which explains how caching for resources
is properly applied.
--
View this message in context:
http://apache-wicket.1842946.n4.nabble.com/Cache-TextTemplateResourceReferences-tp4432342p4432342.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
--
Martin Grigorov
jWeekend
Training, Consulting, Development
http://jWeekend.com
-
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: Cache TextTemplateResourceReferences
oops, I did not read carefully :-P
it's 'resource' not 'response' so just erase my last post ...
Am 01.03.2012 um 15:31 schrieb Peter Ertl:
just one little addition...
instead of
response.setCacheDuration
use
response.enableCaching(Duration., WebResponse.CacheScope.)
Am 01.03.2012 um 09:08 schrieb Martin Grigorov:
Hi,
I see this is problematic indeed...
Here is how you can achieve this:
class MyPackageTTRR extends TextTemplateResourceReference {
@Override
public IResource getResource() {
ResourceStreamResource resource = (ResourceStreamResource) resource;
resource.setCacheDuration(Duration.xyz);
return resource;
}
}
On Wed, Feb 29, 2012 at 7:52 PM, exaptis david.loid...@gmail.com wrote:
Hi,
i've been following this post in order to generate dynamic JS/CSS files (
https://cwiki.apache.org/WICKET/dynamically-generate-a-css-stylesheet.html
https://cwiki.apache.org/WICKET/dynamically-generate-a-css-stylesheet.html
).
Now I'm expiring white page flickers on page changes inside the browser,
due to the fact that TextTemplateResourceReferences are not versioned
(filename-ver-timestamp.ext) or sent with Cache-Headers (per default
they are delivered with Cache: no-cache). As soon as we have uncached CSS or
JS files FF/IE/Chrome/Safari seem to reload the whole page instead of
applying the cached files and this leads to these annoying page flickers.
So i'm searching for a solution to be able to cache
TextTemplateResourceReferences by enabling the version and setting the cache
headers, but I haven't found a solution yet.
I'm using Wicket 1.5.3.
From a friend of mine I got the tip to check IStaticCacheableResources and
subclass TextTemplateResourceReference in order to return
IStaticCacheableResources, but I didn't have the time yet to test it out.
http://www.jarvana.com/jarvana/view/org/apache/wicket/wicket-core/1.5.0/wicket-core-1.5.0-javadoc.jar!/org/apache/wicket/request/resource/caching/IStaticCacheableResource.html
http://www.jarvana.com/jarvana/view/org/apache/wicket/wicket-core/1.5.0/wicket-core-1.5.0-javadoc.jar!/org/apache/wicket/request/resource/caching/IStaticCacheableResource.html
Any help on this would be really great, as I'm quite new to wicket and
haven't found a good tutorial yet which explains how caching for resources
is properly applied.
--
View this message in context:
http://apache-wicket.1842946.n4.nabble.com/Cache-TextTemplateResourceReferences-tp4432342p4432342.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
--
Martin Grigorov
jWeekend
Training, Consulting, Development
http://jWeekend.com
-
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: http/https in wicket 1.5
You can mark specific pages as HTTPS specific using @requiresHttps. Then just set the ports in your application class. setRootRequestMapper(new HttpsMapper(getRootRequestMapper(), new HttpsConfig(80, 443))); On 1 March 2012 14:10, Douglas Ferguson the...@gmail.com wrote: In 1.4 I had ao code up some interesting work arounds to get my app to redirect between http and https based on which page you are requesting. I remember at the time Igor told me that it would be much easer in 1.5. Can anybody point me in the redirection? I'm considering 2 schemes. 1) Running the entire app over ssl (then I just need to detect http and redirect to https) 2) Keep it as is, Only have the login, signup and payment screens be https and then redirect to http. Regardless I'll need to detect http/https and then redirect if necessary. Would this still be done in the AuthorizationStrategy? I've noticed that RequestCycle has changed, and many methods I used are gone. I.E. I used to use requestCycle.getPageParameters() to get the parameters do that I when I redirected to login I would retain the params, so after logging in the user could be sent to their original page. Douglas - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org -- Fergal Keating IT Senior Engineer --- e. fergal.keat...@directski.com p. NA w. www.directski.com
Re: JavaSerializer - java.util.ConcurrentModificationException during page serialization
Martin, I definitely did a bunch of googling before pinging the mailing list, and also attempted to pinpoint the List throwing the CME. Unfortunately, it was not very easy, as a lot of Lists were being serialized with our pages. Anyway, I think I've finally tracked down the bug. Its cause is related to two issues: 1) A custom, widely-used behavior was holding on to a reference to our custom Session object, causing the Session to be serialized every time a page was serialized. 2) Our Session was not thread-safe, as we incorrectly assumed that the framework took care of that for us. One of the Lists it contains was the one throwing the CME (probably due to a user opening multiple tabs for the same session?) We've fixed both issues, so we'll see how things go. Obviously, this bug was our own doing, but I do think it'd be helpful if the Javadoc for Session and Application mentioned that their thread-safety is up to users. I found out in my copy of Wicket in Action :-). Thanks! On Wed, Feb 29, 2012 at 1:54 AM, Martin Grigorov mgrigo...@apache.orgwrote: Hi, On Wed, Feb 29, 2012 at 12:37 AM, Allen Gilbert allen.gilb...@doane.edu wrote: Hello, I'm trying to crack a strange, intermittent bug that's cropped up on our production site. We're using Wicket 1.5.4, and receive the following stack trace a couple times a day under nominal load: 2012-02-23 14:24:57,051 ERROR [ajp-0.0.0.0-8009-2] [org.apache.wicket.serialize.java.JavaSerializer] error writing object [Page class = com.company.web.pages.account.MyAccount, id = 8, render count = 2]: null java.util.ConcurrentModificationException at java.util.ArrayList.writeObject(ArrayList.java:573) at sun.reflect.GeneratedMethodAccessor252.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at java.io.ObjectStreamClass.invokeWriteObject(ObjectStreamClass.java:945) at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1469) ... at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:330) at org.apache.wicket.serialize.java.JavaSerializer$CheckerObjectOutputStream.writeObjectOverride(JavaSerializer.java:250) at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:326) at org.apache.wicket.serialize.java.JavaSerializer.serialize(JavaSerializer.java:77) at org.apache.wicket.pageStore.DefaultPageStore.serializePage(DefaultPageStore.java:368) at org.apache.wicket.pageStore.DefaultPageStore.storePage(DefaultPageStore.java:146) at org.apache.wicket.page.PageStoreManager$PersistentRequestAdapter.storeTouchedPages(PageStoreManager.java:383) at org.apache.wicket.page.RequestAdapter.commitRequest(RequestAdapter.java:171) at org.apache.wicket.page.AbstractPageManager.commitRequest(AbstractPageManager.java:94) at org.apache.wicket.page.PageManagerDecorator.commitRequest(PageManagerDecorator.java:68) at org.apache.wicket.page.PageAccessSynchronizer$2.commitRequest(PageAccessSynchronizer.java:281) at org.apache.wicket.Application$2.onDetach(Application.java:1598) at org.apache.wicket.request.cycle.RequestCycleListenerCollection$3.notify(RequestCycleListenerCollection.java:99) at org.apache.wicket.request.cycle.RequestCycleListenerCollection$3.notify(RequestCycleListenerCollection.java:97) at org.apache.wicket.util.listener.ListenerCollection$1.notify(ListenerCollection.java:119) at org.apache.wicket.util.listener.ListenerCollection.reversedNotify(ListenerCollection.java:143) at org.apache.wicket.util.listener.ListenerCollection.reversedNotifyIgnoringExceptions(ListenerCollection.java:113) at org.apache.wicket.request.cycle.RequestCycleListenerCollection.onDetach(RequestCycleListenerCollection.java:95) at org.apache.wicket.request.cycle.RequestCycle.onDetach(RequestCycle.java:600) at org.apache.wicket.request.cycle.RequestCycle.detach(RequestCycle.java:539) at org.apache.wicket.request.cycle.RequestCycle.processRequestAndDetach(RequestCycle.java:287) at org.apache.wicket.protocol.http.WicketFilter.processRequest(WicketFilter.java:162) at org.apache.wicket.protocol.http.WicketFilter.doFilter(WicketFilter.java:218) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) ... Looking at our logs, there doesn't seem to be anything interesting going on around the time of these exceptions. We're not spawning any threads on our own, and we haven't overridden any serialization-related mechanisms (or defined custom writeObject methods), so I'm at a loss as to where I should look for the cause of this
Re: wicket - check if user is logged (call method in every access to server)
Thanks for help. I try it and I create annotations for classes, that can reject access for user without permissions and user is redirected to LoginPage. But I do not know if it is possible create annotation for methods. If I click on ajax link, same ajax method is called. It is possible to create annotation for the method? To reject access to method and method do not be executed and user will be redirected to LoginPage? How can create it? How it will be register in my application? Thanks. -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/wicket-check-if-user-is-logged-call-method-in-every-access-to-server-tp4431837p4435542.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
AjaxFormSubmitBehaviour
Hi, I''ve upgraded my wicket application from 1.4.6 to 1.4.19. I was using AjaxFormSubmitBehaviour mainly because I need to respond to a change in a radiobox. One main difference was between the versions was the following: In case the form validationg yield errors a screenrefresh is issued, so the form errors could be displayed. In my application it is not appropriate because the radio box changes parts of the screen, and the user does not yet have to have a correctly filled form. How can I suppress this behaviour? How is it possible to use the above behaviour in a manner that it binds all valid values and ignore invalid ones. In 1.4.6 it was the case. Thank you for the answers in advance, Cheers, Tamas -- Cserveny, Tamas - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Wicket on Google App Engine
Daniel, did you ever get things to work to where the HTML files are updated without restarting? Everything is working for me but this part. Thanks. -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Wicket-on-Google-App-Engine-tp4259205p4435831.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: Wicket/Spring Boilerplate
#1 is a wonderful suggestion - was that added in 1.5? #2 I'm not too sure about - doesn't calling getClientInfo() cause a redirect to a temporary page to collect that information? #3 I originally tried it that way, but for some reason, no matter what I did, I couldn't get the filter to recognize the path I set for it. Oddly enough, when I switched to the servlet 3 annotation, it worked. I'd love to back this one out, as it forces a servlet 3 container. Mike -Original Message- From: Martin Grigorov [mailto:mgrigo...@apache.org] Sent: March-01-12 2:51 AM To: users@wicket.apache.org Subject: Re: Wicket/Spring Boilerplate Hi, Thanks for sharing it! Here are some ideas: https://github.com/limone/wicket-spring-boilerplate/blob/master/src/main/resources/archetype-resources/src/main/java/HomePage.java#L25 Better override #renderHead(IHeaderResponse response) and use 'response.renderXYZ()' https://github.com/limone/wicket-spring-boilerplate/blob/master/src/main/resources/archetype-resources/src/main/java/HomePage.java#L20 You can use Session#getClientInfo() to see what is the client and if it IE then contribute this special .js file https://github.com/limone/wicket-spring-boilerplate/blob/master/src/main/resources/archetype-resources/src/main/java/app/WicketFilter.java#L9 I think you can drop this class and configure the original WicketFilter in https://github.com/limone/wicket-spring-boilerplate/blob/master/src/main/resources/archetype-resources/src/main/java/app/WebAppInitializer.java On Thu, Mar 1, 2012 at 2:07 AM, Michael Laccetti mich...@limone.me wrote: Just a quick note to folks that may be interested that I've created a Maven archetype that ties together Wicket 1.5 and Spring 3.1, along with Hibernate 4.1/JPA 2 and logback. It is purely annotation driven, and has no XML configuration files. Currently, users must clone the git repository [1] to use the archetype, but it should be hosted on Sonatype's OSS Nexus shortly. Questions and comments appreciated. :) Michael 1 - https://github.com/limone/wicket-spring-boilerplate -- Martin Grigorov jWeekend Training, Consulting, Development http://jWeekend.com - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Wicket/Spring Boilerplate
On 03/01/2012 02:07 AM, Michael Laccetti wrote: Just a quick note to folks that may be interested that I've created a Maven archetype that ties together Wicket 1.5 and Spring 3.1, along with Hibernate 4.1/JPA 2 and logback. It is purely annotation driven, and has no XML configuration files. Currently, users must clone the git repository [1] to use the archetype, but it should be hosted on Sonatype's OSS Nexus shortly. Questions and comments appreciated. :) Michael, I have an app on wicket 1.4.x, spring 2.5.x and *non-JPA* hibernate 3.5.x. Without taking wicket or other API changes into account, can you suggest whether or even how this archetype could be helpful in migrating to 1.5/3.1/4.1 and perhaps JPA later on? I wouldn't want to migrate to JPA right now. Many thanks for the archetype in any case! Manos - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: AjaxFormSubmitBehaviour
Hi, isn't AjaxFormComponentUpdatingBehavior more suited for your need? Hi, I''ve upgraded my wicket application from 1.4.6 to 1.4.19. I was using AjaxFormSubmitBehaviour mainly because I need to respond to a change in a radiobox. One main difference was between the versions was the following: In case the form validationg yield errors a screenrefresh is issued, so the form errors could be displayed. In my application it is not appropriate because the radio box changes parts of the screen, and the user does not yet have to have a correctly filled form. How can I suppress this behaviour? How is it possible to use the above behaviour in a manner that it binds all valid values and ignore invalid ones. In 1.4.6 it was the case. Thank you for the answers in advance, Cheers, Tamas -- Cserveny, Tamas - 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: AjaxFormSubmitBehaviour
Hi, As far as I know it cannot be user with Radio components. Also if I change the radio values one part of the form will be hidden. If I turn it back I'll need to show the values entered already. Cheers, Tamas -- Cserveny, Tamas On Thu, Mar 1, 2012 at 9:56 PM, Andrea Del Bene an.delb...@gmail.com wrote: Hi, isn't AjaxFormComponentUpdatingBehavior more suited for your need? Hi, I''ve upgraded my wicket application from 1.4.6 to 1.4.19. I was using AjaxFormSubmitBehaviour mainly because I need to respond to a change in a radiobox. One main difference was between the versions was the following: In case the form validationg yield errors a screenrefresh is issued, so the form errors could be displayed. In my application it is not appropriate because the radio box changes parts of the screen, and the user does not yet have to have a correctly filled form. How can I suppress this behaviour? How is it possible to use the above behaviour in a manner that it binds all valid values and ignore invalid ones. In 1.4.6 it was the case. Thank you for the answers in advance, Cheers, Tamas -- Cserveny, Tamas - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: AjaxFormSubmitBehaviour
yes, for radio choice you should use AjaxFormChoiceComponentUpdatingBehavior. Anyway, have you tried setting default form processing to false on AjaxFormSubmitBehavior (setDefaultProcessing(false))? In this way you could save fields' value inside onSubmit() calling updateFormComponentModels() on your form. Hi, As far as I know it cannot be user with Radio components. Also if I change the radio values one part of the form will be hidden. If I turn it back I'll need to show the values entered already. Cheers, Tamas -- Cserveny, Tamas - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Multi Tab and Session
Hi, I started my project with Jetty from within IDEA to use breakpoints and additional informations from the debugger. The Jetty server started without any problems, but when I call localhost:8080, I get he following error: Unexpected Runtime Exception Last cause: Can not determine Markup. Component is not yet connected to a parent. [Page class = org.myproject.PageIndex, id = 0, render count = 1] In my pom.xml, I defined the path to the HTML files for the corresping classes as: build resources resource filteringfalse/filtering directorysrc/main/resources/directory /resource resource directorysrc/main/html/directory /resource resource filteringfalse/filtering directorysrc/main/java/directory includes include**/include /includes excludes exclude**/*.java/exclude /excludes /resource /resources testResources testResource filteringfalse/filtering directorysrc/test/resources/directory /testResource testResource directorysrc/main/html/directory /testResource testResource filteringfalse/filtering directorysrc/test/java/directory includes include**/include /includes excludes exclude**/*.java/exclude /excludes /testResource /testResources plugins plugin Seems to me, that Jetty does not find the .html files? Andre On Thu, 1 Mar 2012 10:13:00 +0200 Martin Grigorov mgrigo...@apache.org wrote: Use mvnDebug instead of mvn at the command line. This will start it in debug mode and you can attach to it from IDEA. Otherwise Wicket quickstart comes with src/test/java/**/Start.java. Run this class as normal Java application with main(String[]). From the context menu in the .java file choose Debug 'Start.main()' 2012/3/1 André Schütz andre-p...@gmx.de: Hi Martin, I compile the wicket project via Maven from the command line. I do not use the IDE to start the project and trace it? Do you have a hint how I can do that? As IDE, Ia m using IntelliJ IDEA. Andre Original-Nachricht Datum: Thu, 1 Mar 2012 09:40:30 +0200 Von: Martin Grigorov mgrigo...@apache.org An: users@wicket.apache.org Betreff: Re: Multi Tab and Session 2012/2/29 Andre Schütz andre-p...@gmx.de: Hi, I could identify the cause of the problem, but still have no solution. I set some breakpoints and made some output messages to trace the system. The following thinks happened: (1) I submit a search in Tab1. The search word will be passed as Page Parameter to Page2 in Tab1. While Tab1 is showing the loading animation with it AjaxSelfUpdatingTimerBehavior, I submit a second search in Tab2. Tab2 switches to its Page2 and the loading animation stops in both Tabs. Reason: -- The constructors of Page2 is called twice on the two Tabs. As diagram: 01.) Tab1: Page1 submit search 02.) Tab1: Page2 (Page id = 14) calls its constructor and adds a PanelA 03.) Tab1: shows loading animation with its AjaxSelfUpdatingTimerBehavior at PanelA 04.) Tab2: Page1 submit search 05.) Tab2: Page2 (Page id = 16) calls its constructor and adds a PanelA 06.) Tab2: shows loading animation with its AjaxSelfUpdatingTimerBehavior at PanelA 07.) Tab1: Page2 (Page id = 17) calls its constructor 08.) Tab1: does not update anymore 09.) Tab2: Page2 (Page id = 18) calls its constructor 10.) Tab2: does not update anymore I do nothing from the beginning of step 7 and do not know why the constructor is called again. Put a breakpoint in Page2 constructor and see why it is called. (2) The same odd behavior happens, when I do the following. I submit a search in Tab1 from its Page1. While the loading animation is shown, I reload the Page1 in Tab2. The constructor of Page2 in Tab1 is called again and the Page2 in Tab1 stops its update progress. As diagram: 01.) Tab1: Page1 submit search 02.) Tab1: Page2 (Page id = 22) calls its constructor and adds a PanelA 03.) Tab1: shows loading animation with its AjaxSelfUpdatingTimerBehavior at PanelA 04.) Tab2: Reload any Page 05.) Tab1: Page2 (Page id = 23) calls its constructor 06.) Tab1: does not update anymore I really can't explain to myself, why the constructor is called again. But I think that this second call in the individual Tabs is crashing my application. Any ideas about this odd behavior? Thank in advance, Andre On Wed, 29 Feb 2012 10:10:37 -0800 Dan
Re: Multi Tab and Session
Hi Dan, I made an output of the PageIDs and got the following result: When I reload Page1 in Tab2, the page id is different from the page id of Page2 in Tab1. Additionally, this reload of Tab1 while making a reload of Tab2 occurs in any browser. Tested it with Opera, Firefox and IE. Andre On Wed, 29 Feb 2012 20:46:22 -0800 Dan Retzlaff dretzl...@gmail.com wrote: I reproduced part of your setup with the attached quickstart whose homepage updates a single label with an AjaxSelfUpdatingTimerBehavior. Reloading a page in a second tab (including its version number in the URL) causes subsequent requests to the first tab to be considered stale based on a page render count. This stops the AJAX updates. So Andre, when you load Page1 in Tab2, does your request include the page ID from Tab1? If this isn't the case, then please share a quickstart of your own. Despite your detailed description I'm not sure I'm reproducing your steps exactly. Regarding multiple constructor calls, are you using Chrome 17 or greater? It introduces some funky prerendering business that can cause multiple requests/constructions when you'd otherwise expect one. I just learned this today. Typing localhost:8080 into address bar is enough to make the request, even without hitting enter. Hitting enter causes another request to be made, but it appears it is the first response that is rendered (based on the page ID in the URL). Interesting. http://code.google.com/chrome/whitepapers/prerender.html Dan 2012/2/29 Andre Schütz andre-p...@gmx.de Hi, I could identify the cause of the problem, but still have no solution. I set some breakpoints and made some output messages to trace the system. The following thinks happened: (1) I submit a search in Tab1. The search word will be passed as Page Parameter to Page2 in Tab1. While Tab1 is showing the loading animation with it AjaxSelfUpdatingTimerBehavior, I submit a second search in Tab2. Tab2 switches to its Page2 and the loading animation stops in both Tabs. Reason: -- The constructors of Page2 is called twice on the two Tabs. As diagram: 01.) Tab1: Page1 submit search 02.) Tab1: Page2 (Page id = 14) calls its constructor and adds a PanelA 03.) Tab1: shows loading animation with its AjaxSelfUpdatingTimerBehavior at PanelA 04.) Tab2: Page1 submit search 05.) Tab2: Page2 (Page id = 16) calls its constructor and adds a PanelA 06.) Tab2: shows loading animation with its AjaxSelfUpdatingTimerBehavior at PanelA 07.) Tab1: Page2 (Page id = 17) calls its constructor 08.) Tab1: does not update anymore 09.) Tab2: Page2 (Page id = 18) calls its constructor 10.) Tab2: does not update anymore I do nothing from the beginning of step 7 and do not know why the constructor is called again. (2) The same odd behavior happens, when I do the following. I submit a search in Tab1 from its Page1. While the loading animation is shown, I reload the Page1 in Tab2. The constructor of Page2 in Tab1 is called again and the Page2 in Tab1 stops its update progress. As diagram: 01.) Tab1: Page1 submit search 02.) Tab1: Page2 (Page id = 22) calls its constructor and adds a PanelA 03.) Tab1: shows loading animation with its AjaxSelfUpdatingTimerBehavior at PanelA 04.) Tab2: Reload any Page 05.) Tab1: Page2 (Page id = 23) calls its constructor 06.) Tab1: does not update anymore I really can't explain to myself, why the constructor is called again. But I think that this second call in the individual Tabs is crashing my application. Any ideas about this odd behavior? Thank in advance, Andre On Wed, 29 Feb 2012 10:10:37 -0800 Dan Retzlaff dretzl...@gmail.com wrote: Your description is clear, thank you. I'm not certain that the background thread's reference to the Session is valid outside of the servlet request. I would verify your assumption by logging the session's object ID when the value is read/written. I have one other thought for you. I believe Wicket keeps the most recent page in a deserialized state to save itself the work of deserialization in the common case of it being required by the next request. (I think the logic is in PageStoreManager, but it's not clear to me. Hopefully a dev can confirm/correct me.) At any rate, this may cause the difference between your two scenarios. In your successful, single-tab scenario, you may be benefiting from a lack of serialization/deserialization round-trip. We have noticed this difference when our components have transient variables that aren't set to null in detach(): in the most recent page the variable remains not-null; if the session has intermediate requests for other pages, the variable is null when next accessed. Good luck, Dan 2012/2/29 André Schütz andre-p...@gmx.de Hi, Page1 gets the click of the submit button and collects the search word.
Re: http/https in wicket 1.5
Wow.. that is much easier :) Is there a way to set a default for the entire app? I assume if I have a base class for a bunch of pages I only need to define it in the parent class? Douglas On Mar 1, 2012, at 10:04 AM, Fergal Keating wrote: You can mark specific pages as HTTPS specific using @requiresHttps. Then just set the ports in your application class. setRootRequestMapper(new HttpsMapper(getRootRequestMapper(), new HttpsConfig(80, 443))); On 1 March 2012 14:10, Douglas Ferguson the...@gmail.com wrote: In 1.4 I had ao code up some interesting work arounds to get my app to redirect between http and https based on which page you are requesting. I remember at the time Igor told me that it would be much easer in 1.5. Can anybody point me in the redirection? I'm considering 2 schemes. 1) Running the entire app over ssl (then I just need to detect http and redirect to https) 2) Keep it as is, Only have the login, signup and payment screens be https and then redirect to http. Regardless I'll need to detect http/https and then redirect if necessary. Would this still be done in the AuthorizationStrategy? I've noticed that RequestCycle has changed, and many methods I used are gone. I.E. I used to use requestCycle.getPageParameters() to get the parameters do that I when I redirected to login I would retain the params, so after logging in the user could be sent to their original page. Douglas - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org -- Fergal Keating IT Senior Engineer --- e. fergal.keat...@directski.com p. NA w. www.directski.com - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
RE: Wicket/Spring Boilerplate
Michael, I have an app on wicket 1.4.x, spring 2.5.x and *non-JPA* hibernate 3.5.x. Without taking wicket or other API changes into account, can you suggest whether or even how this archetype could be helpful in migrating to 1.5/3.1/4.1 and perhaps JPA later on? I wouldn't want to migrate to JPA right now. Many thanks for the archetype in any case! Manos There's not much to getting JPA to work vs. Hibernate - the boilerplate is set to use Hibernate specifically for JPA. The only changes required would be performed in the SpringConfiguration class - you'd remove the LocalContainerEntityManagerFactoryBean (say that fast). Instead, you'd use a LocalSessionFactoryBean that spits out the Hibernate SessionFactory object. You could then remove the JpaVendorAdapter method and change the TransactionManager method to return a HibernateTransactionManager. Everything else should stay entirely the same. Michael - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
RE: wiquery css
Me again, I figured it all out and it work beautifully ... when deployed in weblogic. For my production environment I unfortunately have to use oc4j, and somehow I'm unable to load the resource in this environment: 2012-03-01 20:51:03,471 WARN (PackageResource.java:594) - Unable to find package resource [path = org/odlabs/wiquery/ui/themes/mytheme/jquery-ui-1.8.18.custom.min.css, style = null, locale = null] Maybe this is not the right forum, but perhaps someone has an idea. Thanks! Natalie -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/wiquery-css-tp4407116p4437198.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
Adding a header contribution as the first in the head tag
I'm trying to add an IE compatibility meta tag and it needs to be the first item in the head tag otherwise it will not work. I have a BasePage that I can just put it in the html and that works fine for the most part but I would like a way to set it in the Application class that way any page will get the contribution. Is there any way to do this in wicket 1.5? Thanks, Josh
The vision of Wicket 6
Just a non-technical question. We're using Wicket 1.4.x and 1.5.x in different projects and we're feeling quite confident (at least me) using this framework. By the way, it might be not quite easy migrating an existing wicket 1.4 project to wicket 1.5. But that's not the point. I've noticed, that the guys are working on a new wicket version, called Wicket 6.0. What is the aim of Wicket 6? What is the vision with wicket 6? Why this major release number? Is Wicket 6 not just a Wicket 2? Is closer to wicket 1.5 than the version number 6 will -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/The-vision-of-Wicket-6-tp4437642p4437642.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
The vision of Wicket 6
Just a non-technical question. We're using Wicket 1.4.x and 1.5.x in different projects and we're feeling quite confident (at least me) using this framework. By the way, it might be not quite easy migrating an existing wicket 1.4 project to wicket 1.5. But that's not the point. I've noticed, that the guys are working on a new wicket version, called Wicket 6.0. What is the aim of Wicket 6? What is the vision with wicket 6? Why this major release number? Is Wicket 6 not just a Wicket 2? Is not the API closer to wicket 1.5 than the version number 6 will suggest? -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/The-vision-of-Wicket-6-tp4437649p4437649.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: The vision of Wicket 6
Hi Dirk, starting with Wicket 6 we'll adhere to semantic versioning (see http://semver.org) , thus the big leap in the version number. Is not the API closer to wicket 1.5 than the version number 6 will suggest? I'd say that version 6.0.0 will be closer to 1.5.x than 1.5.0 was to 1.4.x. Depending on what features you use intensively your mileage may vary though. Hope this helps Sven On 03/02/2012 08:09 AM, Dirk Forchel wrote: Just a non-technical question. We're using Wicket 1.4.x and 1.5.x in different projects and we're feeling quite confident (at least me) using this framework. By the way, it might be not quite easy migrating an existing wicket 1.4 project to wicket 1.5. But that's not the point. I've noticed, that the guys are working on a new wicket version, called Wicket 6.0. What is the aim of Wicket 6? What is the vision with wicket 6? Why this major release number? Is Wicket 6 not just a Wicket 2? Is not the API closer to wicket 1.5 than the version number 6 will suggest? -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/The-vision-of-Wicket-6-tp4437649p4437649.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 - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: The vision of Wicket 6
Hi, Here is the roadmap for 6.0: https://cwiki.apache.org/WICKET/wicket-60-roadmap.html Wicket 2.0 has been already used for an experimental branch (in the time 1.2 was the production version) so it cannot be reused. Wicket 6.0 will require JDK 6 so we decided to follow SUN : JDK 1.5 - JDK 6.0 :-) Wicket 7.0 may or may not require JDK 7.0 as minimum. On Fri, Mar 2, 2012 at 9:32 AM, Sven Meier s...@meiers.net wrote: Hi Dirk, starting with Wicket 6 we'll adhere to semantic versioning (see http://semver.org) , thus the big leap in the version number. Is not the API closer to wicket 1.5 than the version number 6 will suggest? I'd say that version 6.0.0 will be closer to 1.5.x than 1.5.0 was to 1.4.x. Depending on what features you use intensively your mileage may vary though. Hope this helps Sven On 03/02/2012 08:09 AM, Dirk Forchel wrote: Just a non-technical question. We're using Wicket 1.4.x and 1.5.x in different projects and we're feeling quite confident (at least me) using this framework. By the way, it might be not quite easy migrating an existing wicket 1.4 project to wicket 1.5. But that's not the point. I've noticed, that the guys are working on a new wicket version, called Wicket 6.0. What is the aim of Wicket 6? What is the vision with wicket 6? Why this major release number? Is Wicket 6 not just a Wicket 2? Is not the API closer to wicket 1.5 than the version number 6 will suggest? -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/The-vision-of-Wicket-6-tp4437649p4437649.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 - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org -- Martin Grigorov jWeekend Training, Consulting, Development http://jWeekend.com - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Wicket/Spring Boilerplate
On Thu, Mar 1, 2012 at 8:49 PM, Michael Laccetti mich...@limone.me wrote: #1 is a wonderful suggestion - was that added in 1.5? No, it is old. #2 I'm not too sure about - doesn't calling getClientInfo() cause a redirect to a temporary page to collect that information? No, this info will be extracted from the User-Agent header. The extended info like browser dimensions are extracted with the special page. #3 I originally tried it that way, but for some reason, no matter what I did, I couldn't get the filter to recognize the path I set for it. Oddly enough, when I switched to the servlet 3 annotation, it worked. I'd love to back this one out, as it forces a servlet 3 container. Mike -Original Message- From: Martin Grigorov [mailto:mgrigo...@apache.org] Sent: March-01-12 2:51 AM To: users@wicket.apache.org Subject: Re: Wicket/Spring Boilerplate Hi, Thanks for sharing it! Here are some ideas: https://github.com/limone/wicket-spring-boilerplate/blob/master/src/main/resources/archetype-resources/src/main/java/HomePage.java#L25 Better override #renderHead(IHeaderResponse response) and use 'response.renderXYZ()' https://github.com/limone/wicket-spring-boilerplate/blob/master/src/main/resources/archetype-resources/src/main/java/HomePage.java#L20 You can use Session#getClientInfo() to see what is the client and if it IE then contribute this special .js file https://github.com/limone/wicket-spring-boilerplate/blob/master/src/main/resources/archetype-resources/src/main/java/app/WicketFilter.java#L9 I think you can drop this class and configure the original WicketFilter in https://github.com/limone/wicket-spring-boilerplate/blob/master/src/main/resources/archetype-resources/src/main/java/app/WebAppInitializer.java On Thu, Mar 1, 2012 at 2:07 AM, Michael Laccetti mich...@limone.me wrote: Just a quick note to folks that may be interested that I've created a Maven archetype that ties together Wicket 1.5 and Spring 3.1, along with Hibernate 4.1/JPA 2 and logback. It is purely annotation driven, and has no XML configuration files. Currently, users must clone the git repository [1] to use the archetype, but it should be hosted on Sonatype's OSS Nexus shortly. Questions and comments appreciated. :) Michael 1 - https://github.com/limone/wicket-spring-boilerplate -- Martin Grigorov jWeekend Training, Consulting, Development http://jWeekend.com - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org -- Martin Grigorov jWeekend Training, Consulting, Development http://jWeekend.com - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: http/https in wicket 1.5
On Fri, Mar 2, 2012 at 2:51 AM, Douglas Ferguson the...@gmail.com wrote: Wow.. that is much easier :) Is there a way to set a default for the entire app? I assume if I have a base class for a bunch of pages I only need to define it in the parent class? Yes. On an interface as well. Douglas On Mar 1, 2012, at 10:04 AM, Fergal Keating wrote: You can mark specific pages as HTTPS specific using @requiresHttps. Then just set the ports in your application class. setRootRequestMapper(new HttpsMapper(getRootRequestMapper(), new HttpsConfig(80, 443))); On 1 March 2012 14:10, Douglas Ferguson the...@gmail.com wrote: In 1.4 I had ao code up some interesting work arounds to get my app to redirect between http and https based on which page you are requesting. I remember at the time Igor told me that it would be much easer in 1.5. Can anybody point me in the redirection? I'm considering 2 schemes. 1) Running the entire app over ssl (then I just need to detect http and redirect to https) 2) Keep it as is, Only have the login, signup and payment screens be https and then redirect to http. Regardless I'll need to detect http/https and then redirect if necessary. Would this still be done in the AuthorizationStrategy? I've noticed that RequestCycle has changed, and many methods I used are gone. I.E. I used to use requestCycle.getPageParameters() to get the parameters do that I when I redirected to login I would retain the params, so after logging in the user could be sent to their original page. Douglas - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org -- Fergal Keating IT Senior Engineer --- e. fergal.keat...@directski.com p. NA w. www.directski.com - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org -- Martin Grigorov jWeekend Training, Consulting, Development http://jWeekend.com - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: wicket - check if user is logged (call method in every access to server)
Hi, This is not directly supported by the auth strategies. A callback method (like onClick) cannot be executed for invisible or disabled components/behaviors. So if the auth strategy forbid the component then the component itself and all its behaviors wont be reachable in the next request. On Thu, Mar 1, 2012 at 6:54 PM, Dan12321 wee...@centrum.cz wrote: Thanks for help. I try it and I create annotations for classes, that can reject access for user without permissions and user is redirected to LoginPage. But I do not know if it is possible create annotation for methods. If I click on ajax link, same ajax method is called. It is possible to create annotation for the method? To reject access to method and method do not be executed and user will be redirected to LoginPage? How can create it? How it will be register in my application? Thanks. -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/wicket-check-if-user-is-logged-call-method-in-every-access-to-server-tp4431837p4435542.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 -- Martin Grigorov jWeekend Training, Consulting, Development http://jWeekend.com - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
