Wicket 1.5 and weird error on redirect

2011-12-18 Thread Guillaume Smet
Hello,

We are currently migrating our applications from Wicket 1.4 to 1.5.

I have a problem with a pattern we use for logout, namely:
public class LogoutPage extends WebPage {
public LogoutPage() {
AuthenticatedWebSession session = AuthenticatedWebSession.get();
if (session != null) {
session.invalidate();
}


setResponsePage(CoreWicketAuthenticatedApplication.get().getSignInPageClass());
}
}

In Wicket 1.4, it worked perfectly. The only change I made is that I
had to remove the setRedirect(true) for 1.5.

With 1.5, when I click on a bookmarkable link pointing to LogoutPage,
I have the following error:
org.apache.wicket.markup.MarkupNotFoundException: Can not determine
Markup. Component is not yet connected to a parent. [Page class =
fr.openwide.core.wicket.more.security.page.LogoutPage, id = 86, render
count = 1]
 at org.apache.wicket.Component.getMarkup(Component.java:731)
 at org.apache.wicket.Component.internalRender(Component.java:2312)
 at org.apache.wicket.Component.render(Component.java:2275)
 at org.apache.wicket.Page.renderPage(Page.java:1035)
 at 
org.apache.wicket.request.handler.render.WebPageRenderer.renderPage(WebPageRenderer.java:105)
 at 
org.apache.wicket.request.handler.render.WebPageRenderer.respond(WebPageRenderer.java:224)
 at 
org.apache.wicket.request.handler.RenderPageRequestHandler.respond(RenderPageRequestHandler.java:167)
 at 
org.apache.wicket.request.cycle.RequestCycle$HandlerExecutor.respond(RequestCycle.java:750)
 at 
org.apache.wicket.request.RequestHandlerStack.execute(RequestHandlerStack.java:64)
 at 
org.apache.wicket.request.cycle.RequestCycle.execute(RequestCycle.java:252)
 at 
org.apache.wicket.request.cycle.RequestCycle.processRequest(RequestCycle.java:209)
 at 
org.apache.wicket.request.cycle.RequestCycle.processRequestAndDetach(RequestCycle.java:280)
 at 
org.apache.wicket.protocol.http.WicketFilter.processRequest(WicketFilter.java:162)
 at 
org.apache.wicket.protocol.http.WicketFilter.doFilter(WicketFilter.java:218)

Any idea on why it doesn't work anymore and how I can fix it?

Thanks.

-- 
Guillaume

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: Wicket 1.5 and weird error on redirect

2011-12-18 Thread Guillaume Smet
Hi Dan,

On Sun, Dec 18, 2011 at 11:29 PM, Dan Retzlaff dretzl...@gmail.com wrote:
 Try throwing RestartResponseException instead of calling setResponsePage.
 This will stop the construction of your StopPage immediately.

Thanks for your answer.

Using throw new RestartResponseException(clazz); was indeed my next
move but I was wondering if this behaviour with setResponsePage() was
expected.

It works with the exception so I'll go change that everywhere I use
setResponsePage in a page.

Regards,

-- 
Guillaume

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: mapping / mounting of PIE.htc for IE

2012-04-03 Thread Guillaume Smet
Hi Bert,

On Tue, Apr 3, 2012 at 11:25 AM, Bert taser...@gmail.com wrote:
 I have to switch to absolute URLs for this. Thanks for reading

It's not exactly the best solution in the world but, considering that
PIE.htc is a hack, we use a pretty hackish solution: we declare all
the styles on which we want to enable the PIE.htc filter directly in
the page surrounded by a test on the IE version.

This way, we can easily get the relative PIE.htc URL from Wicket.

-- 
Guillaume

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Invalid URL generated when jsessionid is present

2012-05-10 Thread Guillaume Smet
Hi,

Under certain circumstances when we navigate on our Wicket site,
Wicket generates the following URL for a bookmarkable page link:
/mount/point/.;jsessionid=C94BC23C58FD2972B34E5DE145C076BB

The dot before the ;jsessionid= makes the mount point not recognized by Wicket.

The problem is when I click on a link pointing to the exact same page
I'm visiting.

Any idea on how to fix it?

Thanks.

-- 
Guillaume

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: Invalid URL generated when jsessionid is present

2012-05-11 Thread Guillaume Smet
Hi Martin,

On Fri, May 11, 2012 at 9:43 AM, Martin Grigorov mgrigo...@apache.org wrote:
 Upgrade to 1.5.6.

Oh? I haven't found any JIRA on this very subject but I might have missed it.

I usually upgrade very quickly after a release but the issue with
stateless page + feedback fixed after the release is kinda annoying
for us.

That said, I'll test 1.5.6 to see if it fixes the problem and I'll
decide what I do after that.

Thanks for your quick answer and have a nice day.

-- 
Guillaume

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: Invalid URL generated when jsessionid is present

2012-05-11 Thread Guillaume Smet
On Fri, May 11, 2012 at 11:05 AM, Martin Grigorov mgrigo...@apache.org wrote:
 There is a workaround for this. See the ticket for 1.5.7.

Thanks for the pointer.

I can confirm that the problem is fixed in 1.5.6.

Thanks.

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Wicket 1.5.6, Ajax and expired page

2012-05-14 Thread Guillaume Smet
Hi,

I noticed this evening that when a page is expired, if we make an Ajax
call from this page (autocomplete for example), the Ajax call returns
a 302 and then the entire page content (and not a valid XML Ajax
response) - I investigated it with Firebug as there's no error
anywhere.

Could it be related to WICKET-4454 ? We upgraded to 1.5.6 a few days ago.

It might be that I never waited long enough to see the problem before
but I'm pretty sure it was working correctly in previous versions.

Thanks for your feedback.

-- 
Guillaume

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: Wicket 1.5.6, Ajax and expired page

2012-05-15 Thread Guillaume Smet
Hi Martin,

On Tue, May 15, 2012 at 8:44 AM, Martin Grigorov mgrigo...@apache.org wrote:
 Since https://issues.apache.org/jira/browse/WICKET-4014 (Wicket 1.5.1)
 Wicket is able to handle automatically page expiration for mounted
 pages. I.e. if the user clicks a link and the page is already expired
 then depending on

I followed that and it's quite appreciated to reduce the number of
page expired errors for our users.

The problem I saw yesterday evening on our app is that the Ajax
response was the entire HTML page (raw HTML output) and not a valid
Ajax XML response. I don't think that's something expected.

-- 
Guillaume

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: WiQuery 6.0

2012-10-23 Thread Guillaume Smet
Hi Nick,

On Tue, Oct 23, 2012 at 1:28 AM, Nick Pratt nbpr...@gmail.com wrote:
 I do see the imports of jquery and jquery.ui.autocomplete (which I checked
 are available and served by the web server) - there's just no
 wiquery-gen-uniqueid script in the page

This is a bug.

See my pending pull request here:
https://github.com/WiQuery/wiquery/pull/9

If you don't use autoUpdate, this pull request is sufficient to get
the autocomplete working.

I'm working on another patch to get the autoUpdate feature working.

-- 
Guillaume

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: WiQuery SortableBehavior/DroppableBehavior questions

2012-10-25 Thread Guillaume Smet
Hi Benedikt,

On Thu, Oct 25, 2012 at 6:30 PM, Benedikt Schlegel
codecab.dri...@googlemail.com wrote:
 And i'm having an issue where the drop event isn't fired, when an item is
 dropped at the first position of another sortable. Is anyone else
 experiencing something similar or am I doing it wrong?

This is due to the version of jQuery UI shipped with wiQuery 6.0
(jQuery UI 1.8.16 isn't compatible with jQuery 1.7, see
http://bugs.jqueryui.com/ticket/7852 ).

It's fixed in master as we upgraded jQuery UI to 1.8.24.

I can't help you with the rest of your questions though.

-- 
Guillaume

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: documentation

2013-01-22 Thread Guillaume Smet
Hi Philippe,

On Tue, Jan 22, 2013 at 5:53 PM, Philippe Demaison
ph.demai...@gmail.com wrote:
 Are you kidding ?

First thing first, while everyone agrees that a good documentation is
a good thing, you should consider that you don't pay anyone to write
it.

There are a couple of very good books about Wicket you can purchase at Amazon.

And the Wicket examples library is really nice to understand how
Wicket works and understand the best practices and how you should
build your application.

It took me a couple of hours to start developing my first components
with Wicket, mainly by reading the examples. Probably less than the
time you spent writing your emails.

 http://www.playframework.org/documentation/2.0.4/Home
 http://tapestry.apache.org/documentation.html

I don't know these 2 frameworks and they might (or might not) have a
better documentation than Wicket. The quality of a documentation isn't
measured by the number of pages. You measure it by the time you spend
learning the framework and how useful it is.

 https://developers.google.com/web-toolkit/doc/latest/DevGuide

Well, while you might think at first glance GWT documentation is
better, you're definitely wrong. And, considering the number of
misarchitectured GWT applications I studied (and helped getting them
fixed) for our customers, I'm pretty sure it's not that easy to get it
right from the documentation.

 http://www.springsource.org/spring-framework#documentation

Spring is a framework. Compare with the Spring MVC documentation if
you want to compare Wicket's documentation with something. That said,
I agree that Spring MVC documentation is really good but what really
helps to understand the best practices is the sample applications
developed by SpringSource.

Really try to start learning Wicket by using the available
documentation and especially
http://www.wicket-library.com/wicket-examples/index.html and you'll
see that it's efficient and a good starting point to learn the
framework.

If you don't want to give it a try and see by yourself, well, it's your choice.

But before complaining about the quality of the documentation
available, please consider reading it.

-- 
Guillaume

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: Prioritize header items in html templates

2013-03-19 Thread Guillaume Smet
Hi,

On Tue, Mar 19, 2013 at 2:07 PM, Martin Grigorov mgrigo...@apache.org wrote:
 You can use StringHeaderItem.forString(meta ...) and wrap it in
 PriotityHeaderItem/FilterHeaderItem if needed.

We had the same question. Starting with Wicket 6, title and so on
are lost in the resources lines. It was quite nice to have them on top
of the head and the resources at the bottom of the head,
especially when a customer starts to look at the HTML produced.

I'm not sure having all these tags in the Java code is a good solution
for this issue.

It's mostly cosmetic so it's probably not worth spending too much time
on this but if there is an easy solution for this issue, it might be
worth it.

-- 
Guillaume

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: Prioritize header items in html templates

2013-03-20 Thread Guillaume Smet
On Wed, Mar 20, 2013 at 12:58 PM, Martin Grigorov mgrigo...@apache.org wrote:
 Another user asked the same question so I added it to my demo app:
 https://github.com/martin-g/blogs/commit/d5a248a3a3d5369c9cdc66604eba384428e9d0a0

Thanks Martin.

Very helpful.

-- 
Guillaume

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: Prioritize header items in html templates

2013-03-21 Thread Guillaume Smet
On Wed, Mar 20, 2013 at 11:48 PM, Guillaume Smet
guillaume.s...@gmail.com wrote:
 On Wed, Mar 20, 2013 at 12:58 PM, Martin Grigorov mgrigo...@apache.org 
 wrote:
 Another user asked the same question so I added it to my demo app:
 https://github.com/martin-g/blogs/commit/d5a248a3a3d5369c9cdc66604eba384428e9d0a0

FWIW, the following does the trick for me:
getResourceSettings().setHeaderItemComparator(new
PriorityFirstComparator(true));

The parameter of the PriorityFirstComparator constructor is
renderPageFirst. The default HeaderItemComparator is new
PriorityFirstComparator(false);

-- 
Guillaume

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Link generation from outside of Wicket - was Re: [ANNOUNCE] Apache Wicket 6.7.0 Released!

2013-04-19 Thread Guillaume Smet
Hi,

On Thu, Apr 18, 2013 at 11:36 AM, Martijn Dashorst dasho...@apache.org wrote:
 Render a page or component to a String

 ComponentRenderer exposes two methods: `renderComponent` and
 `renderPage` and they do exactly what their names suggest. Happy
 emailing!

This is really nice. We did it in a quite complicated way before that.

Any chance the same could be done to generate links from outside of
Wicket, which is also quite difficult to get right at the moment?

I'm especially thinking about this recent thread on this subject:
http://markmail.org/thread/a34vmcm6ulxgr3ed

-- 
Guillaume

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: Link generation from outside of Wicket - was Re: [ANNOUNCE] Apache Wicket 6.7.0 Released!

2013-04-19 Thread Guillaume Smet
On Fri, Apr 19, 2013 at 4:30 PM, Martin Grigorov mgrigo...@apache.org wrote:
 What exactly you mean by outside of Wicket ?
 What Wicket objects you have access to ?
 The application name will be needed and a base url. Usually the current
 request's baseUrl is used to construct a full url. Without the base url
 Wicket can generate only context-absolute url.

I'm in exactly the same situation as Martin Dietze.

I have to generate URL to a Wicket page in a batch scheduled by Spring
or Quartz.

We did it following the guidance you gave to Martin but it's quite
complicated. As you mentioned it, we have in a configuration parameter
the scheme/host/port information and we generate an URL to a wicket
page from there by getting the application by its name and building a
fake request and a fake RequestCycle.

FWIW, here is the current version of what we use:
https://gist.github.com/gsmet/5421471

-- 
Guillaume

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: Mount a page class more than once.

2013-05-31 Thread Guillaume Smet
On Fri, May 31, 2013 at 9:37 AM, Martin Grigorov mgrigo...@apache.org wrote:
  #mountPage(/test1.html, MyPageClass1.class)

Moreover, it's usually a good idea to have different classes so you
can build your link to these pages easily.

-- 
Guillaume

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



New Open Source application using Wicket : artifact-listener.org

2013-05-31 Thread Guillaume Smet
Hi,

We wanted to present you our first Open Source application powered by
Wicket. We use Wicket since 1.3 but it's the first application we can
release as an Open Source project.

It's a Maven Central notification service built on Wicket 6.8.0.

Reason why we thought it might be interesting to post this on the list:
- it's in Wicket and Open Source:
https://github.com/openwide-java/artifact-listener/ and it might
contain a few good ideas (at least, we hope so)
- it can be handy to keep track of Wicket releases:
https://www.artifact-listener.org/

Contributions/ideas/questions welcome.

It's a very simple service we plan to maintain for a long time as we
use it to keep track of all the Java components we use in our core
framework.

We have a lot of additional features in mind so stay tuned.

Happy wicketing!

-- 
Guillaume

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Connecting... in Firefox's tab title

2013-06-07 Thread Guillaume Smet
Hi,

For quite a while now, we are seeing a weird behavior with Firefox: as
soon as Wicket does an Ajax call, the tab title is changed to
Connecting... and it doesn't get back to the original page title at
all, even after the Ajax call returned.

Does anybody else see this behavior?

We don't see it with any other site doing Ajax calls, just with Wicket app.

It looks like a detail but it's quite annoying to have a bunch of tabs
named Connecting

Thanks for your feedback.

-- 
Guillaume

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: Connecting... in Firefox's tab title

2013-06-07 Thread Guillaume Smet
Hi,

After some digging, it's related to the multipart ajax request via
posting an iframe.

The iframe is removed in the onload of the iframe ( see
https://github.com/apache/wicket/blob/master/wicket-core/src/main/java/org/apache/wicket/ajax/res/js/wicket-ajax-jquery.js#L868
) and it seems to be problematic for Firefox.

Looks like there is some literature about it here:
http://stackoverflow.com/questions/7285866/never-ending-connecting-message-after-ajax-form-submit

and using a pattern like the following should fix it:
iframe.onload = function(){
// Do work with the content of the iframe…

setTimeout(function(){
iframe.parentNode.removeChild(iframe);
}, 0);
}

Note: we are using Wicket 6.8.0 and Firefox 21.

Should I open a JIRA and should I attach a quickstart to it? I'm AFK
till monday but should be able to do it on monday if needed.

Thanks.

-- 
Guillaume

On Fri, Jun 7, 2013 at 4:34 PM, Guillaume Smet guillaume.s...@gmail.com wrote:
 Hi,

 For quite a while now, we are seeing a weird behavior with Firefox: as
 soon as Wicket does an Ajax call, the tab title is changed to
 Connecting... and it doesn't get back to the original page title at
 all, even after the Ajax call returned.

 Does anybody else see this behavior?

 We don't see it with any other site doing Ajax calls, just with Wicket app.

 It looks like a detail but it's quite annoying to have a bunch of tabs
 named Connecting

 Thanks for your feedback.

 --
 Guillaume

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: Connecting... in Firefox's tab title

2013-06-10 Thread Guillaume Smet
Hi Sven,

On Fri, Jun 7, 2013 at 10:36 PM, Sven Meier s...@meiers.net wrote:
 Yes please. And don't forget to add the collected information to it.

Done: https://issues.apache.org/jira/browse/WICKET-5222

Quickstart and patch attached: it fixes the problem for us.

Thanks.

-- 
Guillaume

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: DiskDataStore errors in production

2014-05-16 Thread Guillaume Smet
On Wed, May 14, 2014 at 9:59 PM, eaglei22 jchojnack...@gmail.com wrote:
 What can be causing these errors? is this more of a Tomcat thing or Wicket?

Hard to guess.

Get the pid of your Tomcat process and use lsof -p pid. You'll see
which files are opened by your Tomcat.

HTH

-- 
Guillaume

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: Wicket / OAuth2

2014-09-02 Thread Guillaume Smet
Hi,

We use Spring Security for Artifact Listener but I think the general
principle should be the same:
https://github.com/openwide-java/artifact-listener/
and you might find it interesting to see how we did it.

Martin already mentioned it earlier but we use pac4j for OpenId/OAuth/whatever.

-- 
Guillaume


On Tue, Sep 2, 2014 at 12:11 PM, Martin Grigorov mgrigo...@apache.org wrote:
 Hi Sebastien,

 The button is just a UI. But the idea is the same.

 The difference is that the OAuth provider is rather an authentication
 service than an authorization one.
 Usually the user of some social network doesn't want to share his details
 with random apps (like yours and mine).
 So when you create an application at Twitter, Facebook, ... you have to
 specify what kind of details you want to be sent to the callback url. When
 an user authenticates (s)he is asked whether (s)he is willing to share
 these details (e.g. username, email, gender, ...). In my experience users
 use OAuth for authentication:
 1) to reduce the number of accounts they have
 2) to reduce the information they provide to random apps

 So (usually) the OAuth provider doesn't send much info about the
 authenticated user when calling your callback. I haven't seen anything like
 roles and privileges in the OAuth responses. It could be that I don't have
 enough experience with OAuth but I think the authorization part is left to
 the application.

 About your use case:
 - the user tries to load some protected resource/page
 - the application should:
 -- store the details about the requested resource (url + post data)
 -- redirect to the authentication url of the OAuth provider by passing the
 callback url
 - if the user agrees to share the required data then your callback url is
 called with the data. You should use it like normal authentication token,
 create a User in the session, etc.

 P.S. I have used a popup window for the authentication because if the user
 is not willing to share all the required info then the oauth provider may
 not call the callback url and your user may not return to your app and make
 a normal account


 Martin Grigorov
 Wicket Training and Consulting
 https://twitter.com/mtgrigorov


 On Tue, Sep 2, 2014 at 12:46 PM, Sebastien seb...@gmail.com wrote:

 Hi Martin,

 The question is not much about having a signin button to authenticate the
 user but more how to make it work with AuthenticatedWebApplication (or a
 custom OAuthWebApplication for instance). The final goal is to keep
 IRoleCheckingStrategy working
 ie: the user access an @AuthorizeInstantiation annotated page,
 #restartResponseAtSignInPage (for instance) redirect to the OAuth url, the
 OAuth service redirect to a callback, which callback is a wicket
 IRequestHandler, the handler sets isSigninedIn to true, sets the roles and
 then call #redirectToOriginalDestination.

 That's how I see things, but I don't see any existing wicket solutions...
 Is the usecase more clear?

 Thanks again,
 Sebastien.



 On Tue, Sep 2, 2014 at 9:06 AM, Martin Grigorov mgrigo...@apache.org
 wrote:

  Hi Sebastien,
 
  What exactly do you need ?
 
  I have used https://github.com/fernandezpablo85/scribe-java to create
  Authenticate with Xyz buttons for signing in (e.g. with Facebook,
 Twitter
  and LinkedIn).
 
  The developer of Scribe doesn't like OAuth2 (as many other developers)
 and
  at some point he stated that he will not merge any new PRs for OAuth2
  impls. I don't see this statement in the README now, so he may have
 changed
  his mind.
 
  Another auth client provider is https://github.com/leleuj/pac4j. I don't
  have experience with it but it looks like well maintained.
 
  Martin Grigorov
  Wicket Training and Consulting
  https://twitter.com/mtgrigorov
 
 
  On Mon, Sep 1, 2014 at 6:58 PM, Sebastien seb...@gmail.com wrote:
 
   Hi all,
  
   AFAIS, there is nothing about a OAuth2 client in Wicket out-of-the-box
 or
   through a satellite project...
  
   Does somebody knows a *simple* solution for integrating OAuth2 into
  Wicket
   (like a OAuthWebApplication, or maybe a ready-to-use Filter, just
 giving
   Consumer Key, Consumer Secret  URLs), without using spring-security
 and
   still keeping advantage of the role-based @AuthorizeInstantiation
   annotation for instance?
  
   Thanks a lot in advance,
   Sebastien.
  
 


-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: [ANNOUNCE] Apache Wicket 6.17.0 released

2014-09-09 Thread Guillaume Smet
Hi,

On Tue, Sep 9, 2014 at 8:46 AM, Martin Grigorov mgrigo...@apache.org wrote:
 I use this URL to check:
 http://central.maven.org/maven2/org/apache/wicket/wicket-core/6.17.0/
 Most probably the index of search.maven.org is broken ...

I reported it to Sonatype:
https://getsatisfaction.com/sonatype/topics/wicket-6-17-0-in-central-but-not-on-search-maven-org
.

We use search.maven.org at artifact-listener.org so Wicket 6.17.0 is
still unannounced there too...

-- 
Guillaume

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: [ANNOUNCE] Apache Wicket 6.17.0 released

2014-09-10 Thread Guillaume Smet
On Tue, Sep 9, 2014 at 9:08 AM, Guillaume Smet guillaume.s...@gmail.com wrote:
 I reported it to Sonatype:
 https://getsatisfaction.com/sonatype/topics/wicket-6-17-0-in-central-but-not-on-search-maven-org

Joel fixed it.

-- 
Guillaume

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Lock timeout per page class

2014-10-21 Thread Guillaume Smet
Hi,

We have a few pages in our application which might take a long time to
generate. This is definitely not the usual case but there are a few of
them.

Thus we were forced to define a high lockTimeout to be sure these
pages can be served.

The fact is that we would really like to have a far lower default
timeout except for these pages.

Is there a way to configure the lockTimeout on a per page basis (I
haven't found one)?

If not, would it be a good idea to provide a way to do so?

Thanks for your feedback.

-- 
Guillaume

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: Lock timeout per page class

2014-10-21 Thread Guillaume Smet
Thanks Martin!

We will give it a try and post what we got.

-- 
Guillaume

On Tue, Oct 21, 2014 at 1:19 PM, Martin Grigorov mgrigo...@apache.org wrote:
 Hi Guillaume,

 You can
 use 
 org.apache.wicket.request.cycle.PageRequestHandlerTracker#getFirstHandler()
 to check what is the requested page in your
 own org.apache.wicket.settings.def.RequestCycleSettings#getTimeout

 Martin Grigorov
 Wicket Training and Consulting
 https://twitter.com/mtgrigorov

 On Tue, Oct 21, 2014 at 1:12 PM, Guillaume Smet guillaume.s...@gmail.com
 wrote:

 Hi,

 We have a few pages in our application which might take a long time to
 generate. This is definitely not the usual case but there are a few of
 them.

 Thus we were forced to define a high lockTimeout to be sure these
 pages can be served.

 The fact is that we would really like to have a far lower default
 timeout except for these pages.

 Is there a way to configure the lockTimeout on a per page basis (I
 haven't found one)?

 If not, would it be a good idea to provide a way to do so?

 Thanks for your feedback.

 --
 Guillaume

 -
 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: Lock timeout per page class

2014-10-21 Thread Guillaume Smet
Hi Martin,

On Tue, Oct 21, 2014 at 1:19 PM, Martin Grigorov mgrigo...@apache.org wrote:
 You can
 use 
 org.apache.wicket.request.cycle.PageRequestHandlerTracker#getFirstHandler()
 to check what is the requested page in your
 own org.apache.wicket.settings.def.RequestCycleSettings#getTimeout

Cute trick but it doesn't work: the timeout is determined once and for
all when the PageAccessSynchronizer is instantiated (see
Session$PageAccessSynchronizerProvider).

And AFAICS, the PageAccessSynchronizer is too low level to be a good
place to manipulate the RequestCycle. Or am I wrong?

-- 
Guillaume

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: Lock timeout per page class

2014-10-23 Thread Guillaume Smet
Hi Martin,

On Wed, Oct 22, 2014 at 9:51 AM, Martin Grigorov mgrigo...@apache.org wrote:
 I'd like to avoid moving the logic that gets the timeout from
 Session.PageAccessSynchronizerProvider to PageAccessSynchronizer because
 this way it will use Application.get() everytime and most apps don't need
 to pay for this.

 A way to make it possible for you is to remove the 'final'
 from org.apache.wicket.Session#getPageManager and introduce overridable
 PageAccessSynchronizer#getTimeout(). This way you can use your own
 PageAccessSynchronizer.
 http://pastie.org/9667070

After a few experiments, here I am!

So, it mostly works: I thought it would be better to add something like:
protected IProviderPageAccessSynchronizer newPageAccessSynchronizerProvider()
{
return new PageAccessSynchronizerProvider();
}
in Session and call it from the constructor instead of removing the
final so I did that in my code.

It works pretty well BUT I haven't found a way to get the page class
in getTimeout without having the risk to trigger a resolvePageInstance
which will try to lock and then call getTimeout leading to a wonderful
stack overflow exception when dealing with
ListenerInterfaceRequestHandler.

Obviously (...) what interests me the most is the getTimeout in
ListenerInterfaceRequestHandler as it's often actions on buttons which
are long to run.

Here is what I have in mind for my Session class:
https://gist.github.com/gsmet/3b9e2775d25fadcef5ef

I must admit that an advice would be welcome as I wouldn't like to
have stack overflow errors popping out in weird edge cases.

Thanks!

-- 
Guillaume

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: Lock timeout per page class

2014-10-24 Thread Guillaume Smet
Hi Martin,

Yeah, I thought about that too but I'm not sure of the best place to
build the pageId - pageClassName map. Any advice about this?

Once I'll get this working, I'll build a PR for the few changes I made
in Wicket (based on what you proposed earlier). Would be nice to have
them in 6.18.

On Fri, Oct 24, 2014 at 8:59 AM, Martin Grigorov mgrigo...@apache.org wrote:
 Hi Guillaume,

 Sorry for not thinking more carefully about this the first time!
 I'm afraid it is not possible to do it the way I suggested.
 PageAccessSynchronizer is the entry point to start using a page and it
 works only with pageId!

 Here is a new hackish approach:
 Store pageId - pageClassName map in the Session. Then when
 PageAccessSynchronizer is requested to lock a page by id use that id to
 resolve the class name and to decide what timeout to use.

 Martin Grigorov
 Wicket Training and Consulting
 https://twitter.com/mtgrigorov

 On Thu, Oct 23, 2014 at 5:44 PM, Guillaume Smet guillaume.s...@gmail.com
 wrote:

 Hi Martin,

 On Wed, Oct 22, 2014 at 9:51 AM, Martin Grigorov mgrigo...@apache.org
 wrote:
  I'd like to avoid moving the logic that gets the timeout from
  Session.PageAccessSynchronizerProvider to PageAccessSynchronizer because
  this way it will use Application.get() everytime and most apps don't need
  to pay for this.
 
  A way to make it possible for you is to remove the 'final'
  from org.apache.wicket.Session#getPageManager and introduce overridable
  PageAccessSynchronizer#getTimeout(). This way you can use your own
  PageAccessSynchronizer.
  http://pastie.org/9667070

 After a few experiments, here I am!

 So, it mostly works: I thought it would be better to add something like:
 protected IProviderPageAccessSynchronizer
 newPageAccessSynchronizerProvider()
 {
 return new PageAccessSynchronizerProvider();
 }
 in Session and call it from the constructor instead of removing the
 final so I did that in my code.

 It works pretty well BUT I haven't found a way to get the page class
 in getTimeout without having the risk to trigger a resolvePageInstance
 which will try to lock and then call getTimeout leading to a wonderful
 stack overflow exception when dealing with
 ListenerInterfaceRequestHandler.

 Obviously (...) what interests me the most is the getTimeout in
 ListenerInterfaceRequestHandler as it's often actions on buttons which
 are long to run.

 Here is what I have in mind for my Session class:
 https://gist.github.com/gsmet/3b9e2775d25fadcef5ef

 I must admit that an advice would be welcome as I wouldn't like to
 have stack overflow errors popping out in weird edge cases.

 Thanks!

 --
 Guillaume

 -
 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: Lock timeout per page class

2014-10-25 Thread Guillaume Smet
Hi Martin,

I got something working with the following changes in Wicket:
https://github.com/openwide-java/wicket/commit/6374a4a7c6fb66841143a88933523f97305cf1a4

Do you consider this commitable? If so, I can create a JIRA issue and push a PR.

Having the pageId in the getTimeout call is quite nice as I don't have
to get it again from the PageRequestHandlerTracker.

Thanks for your feedback.

On Fri, Oct 24, 2014 at 9:16 AM, Martin Grigorov mgrigo...@apache.org wrote:
 If you have a base page then BasePage#onInitialize() should be a good place.
 Or you could add the pageIds of the special/slow pages only in the map.

 Otherwise you may use PageRequestHandlerTracker#getLastHandler in a custom
 IRequestCycleListener#onDetach().

 Martin Grigorov
 Wicket Training and Consulting
 https://twitter.com/mtgrigorov

 On Fri, Oct 24, 2014 at 10:11 AM, Guillaume Smet guillaume.s...@gmail.com
 wrote:

 Hi Martin,

 Yeah, I thought about that too but I'm not sure of the best place to
 build the pageId - pageClassName map. Any advice about this?

 Once I'll get this working, I'll build a PR for the few changes I made
 in Wicket (based on what you proposed earlier). Would be nice to have
 them in 6.18.

 On Fri, Oct 24, 2014 at 8:59 AM, Martin Grigorov mgrigo...@apache.org
 wrote:
  Hi Guillaume,
 
  Sorry for not thinking more carefully about this the first time!
  I'm afraid it is not possible to do it the way I suggested.
  PageAccessSynchronizer is the entry point to start using a page and it
  works only with pageId!
 
  Here is a new hackish approach:
  Store pageId - pageClassName map in the Session. Then when
  PageAccessSynchronizer is requested to lock a page by id use that id to
  resolve the class name and to decide what timeout to use.
 
  Martin Grigorov
  Wicket Training and Consulting
  https://twitter.com/mtgrigorov
 
  On Thu, Oct 23, 2014 at 5:44 PM, Guillaume Smet 
 guillaume.s...@gmail.com
  wrote:
 
  Hi Martin,
 
  On Wed, Oct 22, 2014 at 9:51 AM, Martin Grigorov mgrigo...@apache.org
  wrote:
   I'd like to avoid moving the logic that gets the timeout from
   Session.PageAccessSynchronizerProvider to PageAccessSynchronizer
 because
   this way it will use Application.get() everytime and most apps don't
 need
   to pay for this.
  
   A way to make it possible for you is to remove the 'final'
   from org.apache.wicket.Session#getPageManager and introduce
 overridable
   PageAccessSynchronizer#getTimeout(). This way you can use your own
   PageAccessSynchronizer.
   http://pastie.org/9667070
 
  After a few experiments, here I am!
 
  So, it mostly works: I thought it would be better to add something like:
  protected IProviderPageAccessSynchronizer
  newPageAccessSynchronizerProvider()
  {
  return new PageAccessSynchronizerProvider();
  }
  in Session and call it from the constructor instead of removing the
  final so I did that in my code.
 
  It works pretty well BUT I haven't found a way to get the page class
  in getTimeout without having the risk to trigger a resolvePageInstance
  which will try to lock and then call getTimeout leading to a wonderful
  stack overflow exception when dealing with
  ListenerInterfaceRequestHandler.
 
  Obviously (...) what interests me the most is the getTimeout in
  ListenerInterfaceRequestHandler as it's often actions on buttons which
  are long to run.
 
  Here is what I have in mind for my Session class:
  https://gist.github.com/gsmet/3b9e2775d25fadcef5ef
 
  I must admit that an advice would be welcome as I wouldn't like to
  have stack overflow errors popping out in weird edge cases.
 
  Thanks!
 
  --
  Guillaume
 
  -
  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: Lock timeout per page class

2014-10-28 Thread Guillaume Smet
Hi Martin,

Looks sane to me. I created a JIRA issue:
https://issues.apache.org/jira/browse/WICKET-5740 .

Thanks again for your help!

On Tue, Oct 28, 2014 at 9:45 AM, Martin Grigorov mgrigo...@apache.org wrote:
 Here is my version: http://pastie.org/9680245
 Please create a ticket in JIRA if you like it.

 Martin Grigorov
 Wicket Training and Consulting
 https://twitter.com/mtgrigorov

 On Tue, Oct 28, 2014 at 9:52 AM, Martin Grigorov mgrigo...@apache.org
 wrote:

 Hi,

 I share Sebastien's concern.
 I'll see how to workaround this.

 Martin Grigorov
 Wicket Training and Consulting
 https://twitter.com/mtgrigorov

 On Sat, Oct 25, 2014 at 2:57 PM, Sebastien seb...@gmail.com wrote:

 Hi Guillaume,

 Generally speaking, you cannot call a non final method from a
 constructor...

 Best regards,
 Sebastien
 On Oct 25, 2014 1:32 PM, Guillaume Smet guillaume.s...@gmail.com
 wrote:

  Hi Martin,
 
  I got something working with the following changes in Wicket:
 
 
 https://github.com/openwide-java/wicket/commit/6374a4a7c6fb66841143a88933523f97305cf1a4
 
  Do you consider this commitable? If so, I can create a JIRA issue and
 push
  a PR.
 
  Having the pageId in the getTimeout call is quite nice as I don't have
  to get it again from the PageRequestHandlerTracker.
 
  Thanks for your feedback.
 
  On Fri, Oct 24, 2014 at 9:16 AM, Martin Grigorov mgrigo...@apache.org
  wrote:
   If you have a base page then BasePage#onInitialize() should be a good
  place.
   Or you could add the pageIds of the special/slow pages only in the
 map.
  
   Otherwise you may use PageRequestHandlerTracker#getLastHandler in a
  custom
   IRequestCycleListener#onDetach().
  
   Martin Grigorov
   Wicket Training and Consulting
   https://twitter.com/mtgrigorov
  
   On Fri, Oct 24, 2014 at 10:11 AM, Guillaume Smet 
  guillaume.s...@gmail.com
   wrote:
  
   Hi Martin,
  
   Yeah, I thought about that too but I'm not sure of the best place to
   build the pageId - pageClassName map. Any advice about this?
  
   Once I'll get this working, I'll build a PR for the few changes I
 made
   in Wicket (based on what you proposed earlier). Would be nice to have
   them in 6.18.
  
   On Fri, Oct 24, 2014 at 8:59 AM, Martin Grigorov 
 mgrigo...@apache.org
   wrote:
Hi Guillaume,
   
Sorry for not thinking more carefully about this the first time!
I'm afraid it is not possible to do it the way I suggested.
PageAccessSynchronizer is the entry point to start using a page
 and it
works only with pageId!
   
Here is a new hackish approach:
Store pageId - pageClassName map in the Session. Then when
PageAccessSynchronizer is requested to lock a page by id use that
 id
  to
resolve the class name and to decide what timeout to use.
   
Martin Grigorov
Wicket Training and Consulting
https://twitter.com/mtgrigorov
   
On Thu, Oct 23, 2014 at 5:44 PM, Guillaume Smet 
   guillaume.s...@gmail.com
wrote:
   
Hi Martin,
   
On Wed, Oct 22, 2014 at 9:51 AM, Martin Grigorov 
  mgrigo...@apache.org
wrote:
 I'd like to avoid moving the logic that gets the timeout from
 Session.PageAccessSynchronizerProvider to PageAccessSynchronizer
   because
 this way it will use Application.get() everytime and most apps
  don't
   need
 to pay for this.

 A way to make it possible for you is to remove the 'final'
 from org.apache.wicket.Session#getPageManager and introduce
   overridable
 PageAccessSynchronizer#getTimeout(). This way you can use your
 own
 PageAccessSynchronizer.
 http://pastie.org/9667070
   
After a few experiments, here I am!
   
So, it mostly works: I thought it would be better to add something
  like:
protected IProviderPageAccessSynchronizer
newPageAccessSynchronizerProvider()
{
return new PageAccessSynchronizerProvider();
}
in Session and call it from the constructor instead of removing
 the
final so I did that in my code.
   
It works pretty well BUT I haven't found a way to get the page
 class
in getTimeout without having the risk to trigger a
  resolvePageInstance
which will try to lock and then call getTimeout leading to a
  wonderful
stack overflow exception when dealing with
ListenerInterfaceRequestHandler.
   
Obviously (...) what interests me the most is the getTimeout in
ListenerInterfaceRequestHandler as it's often actions on buttons
  which
are long to run.
   
Here is what I have in mind for my Session class:
https://gist.github.com/gsmet/3b9e2775d25fadcef5ef
   
I must admit that an advice would be welcome as I wouldn't like to
have stack overflow errors popping out in weird edge cases.
   
Thanks!
   
--
Guillaume
   
   
 -
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

ResourceModel with default *key*

2014-11-06 Thread Guillaume Smet
Hi all,

Maybe we are missing something but we haven't found an elegant way to
have a ResourceModel with a default *key* if the current key doesn't
exist.

There is a mechanism for a default *string* but it's not sufficient
for us (we want to be able to specialize the key if needed but have an
internationalized default if not).

Suggestions welcome!

Thanks.

-- 
Guillaume

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: ResourceModel with default *key*

2014-11-06 Thread Guillaume Smet
Hi Tom,

Thanks for your suggestion!

That's the kind of thing I had in mind if we haven't missed anything
in the API but I was hoping we have missed something as it seems
generally useful!

On Thu, Nov 6, 2014 at 12:49 PM, Tom Götz t...@decoded.de wrote:
 You could try something like this: 
 https://gist.github.com/tgoetz/0735b05d47b16acf2fd7 
 https://gist.github.com/tgoetz/0735b05d47b16acf2fd7

 Cheers,
-Tom


 On 06.11.2014, at 11:53, Guillaume Smet guillaume.s...@gmail.com wrote:

 Hi all,

 Maybe we are missing something but we haven't found an elegant way to
 have a ResourceModel with a default *key* if the current key doesn't
 exist.

 There is a mechanism for a default *string* but it's not sufficient
 for us (we want to be able to specialize the key if needed but have an
 internationalized default if not).

 Suggestions welcome!

 Thanks.

 --
 Guillaume


-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: Wicke website makeover time?

2014-11-14 Thread Guillaume Smet
Hi,

Personnally, I really liked what Martijn did here:
http://people.apache.org/~dashorst/wicket-flat/

It's clean and has personnality.

The only thing IMHO is that a one page design for this amount of
information is perhaps a bit too much.

-- 
Guillaume

On Fri, Nov 14, 2014 at 1:14 PM, Chris Colman
chr...@stepaheadsoftware.com wrote:
 I think a multi phase approach might have more chance of success - as
 I
 said in my immediate previous post if we could live with jekyll
 source
 for phase one (even though it may not be ideal) then we can keep most
 of
 the current content source 'as is' and simply choose a decent modern
 Bootstrap CSS template to re-render it in to deliver the best 'bang
 for
 buck' possible at this early stage.

Bootstrap would be too standard and anonymous and would ultimately be
a ball and chain. A little .less and responsiveness can easily be
achieved without going bootstrap.

 IMHO standard and anonymous looks a lot better than retro late 1990s ;)

 Having said that, there are plenty of Bootstrap customization tools
 (Bootswatch etc.,) that would allow us to customize very quickly and so
 move well away from the standard and anonymous Bootstrap look and feel -
 I would never use the standard Bootstrap template without customization
 - it's too generic these days.

 While we could go home grown i.e. without the help of Bootstrap and do
 a little .less (or .sass) and responsiveness the use of Bootstrap's
 already awesome (tried and tested and working) responsiveness and it's
 cross browser compatibility (who wants to deal with issues like that in
 2014?) could make this a very quick project.

 I know I don't have a lot of time to spare to make greenfield, home
 grown responsiveness that works across IE7+, FF, Chrome and Safari.

 So a quick project is a good project for me. If it ends up looking a lot
 more modern and sexy than the current site and it takes hours instead of
 weeks then I think it's going to happen. If we insist on not using a
 grid/CSS/JS template like Bootstrap and so make the effort measured in
 weeks instead of hours then I fear that the website will still have it's
 current look and feel in a years time.

 I don't think we'll be locked into Bootstrap anyway. If the translator
 uses bootstrap then the copy can remain Bootstrap free and easily moved
 to another CSS/JS library later if required.


 Or does Jekyll have a fairly fixed translator that provides little
 customizability?

Jekyll is fully customizable. It's just a translator from markdown to
HTML with templates and includes.

Martijn

-
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