Re: The day Wicket became Apache Wicket 10 years ago!

[SeldonCrisis]

I'm relatively new to Java web dev, so Wicket was pretty intimidating at
first. Thanks to the community and all the posts in this forum, I've gone
from total n00b to somewhat proficient with Wicket. You guys are seriously
some of the most helpful people I've ever known, thanks for all your work!
Here's to your continued success and happiness in the future  

--
View this message in context: 
http://apache-wicket.1842946.n4.nabble.com/The-day-Wicket-became-Apache-Wicket-10-years-ago-tp4678082p4678314.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 do you handle rolling upgrades?

[Martin Makundi]

Also if you shut down sessions, you need a grace period which lengthens the
update time.

2017-07-26 16:05 GMT+03:00 Bas Gooren :

> Hi All,
>
> TL;DR: How/where do you host your wicket apps so you can deploy a new
> version while users are actively using the old/current version? In
> particular: when the new version cannot read the sessions of the old
> version due to page changes.
>
> We’re investigating how we can eliminate downtime in some of our apps while
> we deploy a new version.
>
> Most of the stuff we’ve built in the past could handle 30 sec downtime
> without much issue (e.g. outside office hours).
>
> However, we would like to be able to deploy more often; Perhaps even move
> towards continuous deployment.
>
> Currently, using wicket, this seems problematic due to two reasons:
>
>- Wicket’s sessions (http session and in particular wicket’s filestore)
>require affinity
>- Session incompatibility: new version of app usually cannot deserialize
>old sessions; If we simply take the old version offline, users will
> need to
>start with a fresh session
>
> Since we would like to do deploys without service interruption for active
> users, I imagine something like session draining on the “old” version after
> the “new” version goes online.
> Haproxy has support for this: launch new version and route new users to it,
> put old one in maintenance mode and take it offline when all sessions for
> it have expired (or after predetermined timeout, e.g. 30 minutes).
>
> Most cloud providers (e.g. heroku, jelastic) don’t handle this gracefully
> for as far as I can tell. While they do handle rolling upgrades, they
> assume statelessness or otherwise transferable statefulness (new version
> can read state of old version).
>
> Tomcat has support for parallel deployments ([1]), but I’m not a big fan of
> running multiple apps in a single JVM.
>
> Since we don’t build things that will require massive horizontal
> scalability, powerful virtual servers have always worked great for us.
>
> That means we’ll probably need to put a reverse proxy in between our
> frontend (apache for SSL termination) and app server (tomcat) to handle
> routing.
> But of course, before we build something like that on top of haproxy (or
> other…) I’d like to make sure we’re not reinventing the wheel.
>
> I’m curious how other users of wicket handle this: how do you handle active
> user sessions (with state) when rolling out a new version of your app?
>
> I’d be grateful for any insights and experiences from other wicketeers!
>
> http://tomcat.apache.org/tomcat-8.5-doc/config/context.
> html#Parallel_deployment
>
>
> Met vriendelijke groet,
> Kind regards,
>
> Bas Gooren
>

Re: how to implement resource bundle to get text from the xml file

[extraquoo]

the current project use the i18n xml like below 

 

--
View this message in context: 
http://apache-wicket.1842946.n4.nabble.com/how-to-implement-resource-bundle-to-get-text-from-the-xml-file-tp4678278p4678312.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 do you handle rolling upgrades?

[Bas Gooren]

Hi All,

TL;DR: How/where do you host your wicket apps so you can deploy a new
version while users are actively using the old/current version? In
particular: when the new version cannot read the sessions of the old
version due to page changes.

We’re investigating how we can eliminate downtime in some of our apps while
we deploy a new version.

Most of the stuff we’ve built in the past could handle 30 sec downtime
without much issue (e.g. outside office hours).

However, we would like to be able to deploy more often; Perhaps even move
towards continuous deployment.

Currently, using wicket, this seems problematic due to two reasons:

   - Wicket’s sessions (http session and in particular wicket’s filestore)
   require affinity
   - Session incompatibility: new version of app usually cannot deserialize
   old sessions; If we simply take the old version offline, users will need to
   start with a fresh session

Since we would like to do deploys without service interruption for active
users, I imagine something like session draining on the “old” version after
the “new” version goes online.
Haproxy has support for this: launch new version and route new users to it,
put old one in maintenance mode and take it offline when all sessions for
it have expired (or after predetermined timeout, e.g. 30 minutes).

Most cloud providers (e.g. heroku, jelastic) don’t handle this gracefully
for as far as I can tell. While they do handle rolling upgrades, they
assume statelessness or otherwise transferable statefulness (new version
can read state of old version).

Tomcat has support for parallel deployments ([1]), but I’m not a big fan of
running multiple apps in a single JVM.

Since we don’t build things that will require massive horizontal
scalability, powerful virtual servers have always worked great for us.

That means we’ll probably need to put a reverse proxy in between our
frontend (apache for SSL termination) and app server (tomcat) to handle
routing.
But of course, before we build something like that on top of haproxy (or
other…) I’d like to make sure we’re not reinventing the wheel.

I’m curious how other users of wicket handle this: how do you handle active
user sessions (with state) when rolling out a new version of your app?

I’d be grateful for any insights and experiences from other wicketeers!

http://tomcat.apache.org/tomcat-8.5-doc/config/context.html#Parallel_deployment


Met vriendelijke groet,
Kind regards,

Bas Gooren

Re: NPE in org.apache.wicket.request.http.handler.RedirectRequestHandler.respond

[Martin Grigorov]

I've added a check for 7.x and 8.x -
https://git1-us-west.apache.org/repos/asf?p=wicket.git;a=commitdiff;h=5f3fc484;hp=3ec2c617f1e27f06df985032e233ca4799097b26

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

On Wed, Jul 26, 2017 at 1:48 PM, Martin Grigorov 
wrote:

> https://github.com/apache/wicket/blob/wicket-6.17.0/
> wicket-request/src/main/java/org/apache/wicket/request/http/handler/
> RedirectRequestHandler.java#L99 says that getRedirectUrl() returns null.
> So something calls RedirectRequestHandler's constructor with null url.
> Wicket doesn't instantiate this class for its needs, so it should be your
> application.
>
> Martin Grigorov
> Wicket Training and Consulting
> https://twitter.com/mtgrigorov
>
> On Wed, Jul 26, 2017 at 10:15 AM, Wayne W 
> wrote:
>
>> Still on 6.17.0 Martin. Not had the time/resources to move to 6.18 which I
>> want because of that replication fix!!
>>
>> On Tue, Jul 25, 2017 at 7:55 PM, Martin Grigorov 
>> wrote:
>>
>> > Which version of Wicket do you use ?
>> >
>> > Martin Grigorov
>> > Wicket Training and Consulting
>> > https://twitter.com/mtgrigorov
>> >
>> > On Tue, Jul 25, 2017 at 5:52 PM, Wayne W 
>> > wrote:
>> >
>> > > Hi,
>> > >
>> > > I've got a strange issue I cannot get to the bottom of. Basically we
>> have
>> > > our app deployed on jetty 9.2.1 with apache 2.4 in front. If I make
>> calls
>> > > to stateless pages its all good. However as soon as I try to make a
>> call
>> > to
>> > > a stateful page it does a 302 to the login page for our app, but then
>> > just
>> > > gets stuck in a 302 loop redirection loop. Looking at the server logs
>> its
>> > > full of this with no other exception - each track trace corresponds to
>> > > another 302 redirect. Each redirect is trying to get to our login
>> page:
>> > >
>> > >
>> > > 2017-07-25 14:40:18,989 ERROR -
>> > > org.apache.wicket.DefaultExceptionMapper.internalMap(
>> > > DefaultExceptionMapper.java:129)
>> > > 129 DefaultExceptionMapper - Unexpected error occurred
>> > > java.lang.NullPointerException
>> > > at
>> > > org.apache.wicket.request.http.handler.RedirectRequestHandle
>> r.respond(
>> > > RedirectRequestHandler.java:99)
>> > > at
>> > > org.apache.wicket.request.cycle.RequestCycle$HandlerExecutor.respond(
>> > > RequestCycle.java:862)
>> > > at
>> > > org.apache.wicket.request.RequestHandlerStack.execute(
>> > > RequestHandlerStack.java:64)
>> > > at
>> > > org.apache.wicket.request.RequestHandlerStack.execute(
>> > > RequestHandlerStack.java:93)
>> > > at
>> > > org.apache.wicket.request.cycle.RequestCycle.execute(
>> > > RequestCycle.java:261)
>> > > at
>> > > org.apache.wicket.request.cycle.RequestCycle.
>> > processRequest(RequestCycle.
>> > > java:218)
>> > > at
>> > > org.apache.wicket.request.cycle.RequestCycle.processRequestAndDetach(
>> > > RequestCycle.java:289)
>> > > at
>> > > org.apache.wicket.protocol.http.WicketFilter.processRequestCycle(
>> > > WicketFilter.java:259)
>> > > at
>> > > org.apache.wicket.protocol.http.WicketFilter.
>> > processRequest(WicketFilter.
>> > > java:201)
>> > > at
>> > > org.apache.wicket.protocol.http.WicketFilter.doFilter(
>> > > WicketFilter.java:282)
>> > > at
>> > > org.eclipse.jetty.servlet.ServletHandler$CachedChain.
>> > > doFilter(ServletHandler.java:1653)
>> > > at
>> > > hub.app.servlet.RelativeUrlFilter.doFilter(RelativeUrlFilter.java:54)
>> > > at
>> > > org.eclipse.jetty.servlet.ServletHandler$CachedChain.
>> > > doFilter(ServletHandler.java:1653)
>> > > at
>> > > com.wideplay.warp.persist.PersistenceFilter$3.run(
>> > > PersistenceFilter.java:141)
>> > > at
>> > > com.wideplay.warp.persist.internal.Lifecycles.
>> > > failEarlyAndLeaveNoOneBehind(Lifecycles.java:29)
>> > > at
>> > > com.wideplay.warp.persist.PersistenceFilter.doFilter(
>> > > PersistenceFilter.java:155)
>> > > at
>> > > org.eclipse.jetty.servlet.ServletHandler$CachedChain.
>> > > doFilter(ServletHandler.java:1645)
>> > > at
>> > > org.eclipse.jetty.servlet.ServletHandler.doHandle(
>> > ServletHandler.java:564)
>> > > at
>> > > org.eclipse.jetty.server.handler.ScopedHandler.handle(
>> > > ScopedHandler.java:143)
>> > > at
>> > > org.eclipse.jetty.security.SecurityHandler.handle(
>> > > SecurityHandler.java:578)
>> > > at
>> > > org.eclipse.jetty.server.session.SessionHandler.
>> > > doHandle(SessionHandler.java:221)
>> > > at
>> > > org.eclipse.jetty.server.handler.ContextHandler.
>> > > doHandle(ContextHandler.java:)
>> > > at
>> > > org.eclipse.jetty.servlet.ServletHandler.doScope(
>> > ServletHandler.java:498)
>> > > at
>> > > org.eclipse.jetty.server.session.SessionHandler.
>> > > doScope(SessionHandler.java:183)
>> > > at
>> > > org.eclipse.jetty.server.handler.ContextHandler.
>> > > doScope(ContextHandler.java:1045)
>> > > at
>> 

Re: NPE in org.apache.wicket.request.http.handler.RedirectRequestHandler.respond

[Martin Grigorov]

https://github.com/apache/wicket/blob/wicket-6.17.0/wicket-request/src/main/java/org/apache/wicket/request/http/handler/RedirectRequestHandler.java#L99
says that getRedirectUrl() returns null.
So something calls RedirectRequestHandler's constructor with null url.
Wicket doesn't instantiate this class for its needs, so it should be your
application.

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

On Wed, Jul 26, 2017 at 10:15 AM, Wayne W 
wrote:

> Still on 6.17.0 Martin. Not had the time/resources to move to 6.18 which I
> want because of that replication fix!!
>
> On Tue, Jul 25, 2017 at 7:55 PM, Martin Grigorov 
> wrote:
>
> > Which version of Wicket do you use ?
> >
> > Martin Grigorov
> > Wicket Training and Consulting
> > https://twitter.com/mtgrigorov
> >
> > On Tue, Jul 25, 2017 at 5:52 PM, Wayne W 
> > wrote:
> >
> > > Hi,
> > >
> > > I've got a strange issue I cannot get to the bottom of. Basically we
> have
> > > our app deployed on jetty 9.2.1 with apache 2.4 in front. If I make
> calls
> > > to stateless pages its all good. However as soon as I try to make a
> call
> > to
> > > a stateful page it does a 302 to the login page for our app, but then
> > just
> > > gets stuck in a 302 loop redirection loop. Looking at the server logs
> its
> > > full of this with no other exception - each track trace corresponds to
> > > another 302 redirect. Each redirect is trying to get to our login page:
> > >
> > >
> > > 2017-07-25 14:40:18,989 ERROR -
> > > org.apache.wicket.DefaultExceptionMapper.internalMap(
> > > DefaultExceptionMapper.java:129)
> > > 129 DefaultExceptionMapper - Unexpected error occurred
> > > java.lang.NullPointerException
> > > at
> > > org.apache.wicket.request.http.handler.RedirectRequestHandler.respond(
> > > RedirectRequestHandler.java:99)
> > > at
> > > org.apache.wicket.request.cycle.RequestCycle$HandlerExecutor.respond(
> > > RequestCycle.java:862)
> > > at
> > > org.apache.wicket.request.RequestHandlerStack.execute(
> > > RequestHandlerStack.java:64)
> > > at
> > > org.apache.wicket.request.RequestHandlerStack.execute(
> > > RequestHandlerStack.java:93)
> > > at
> > > org.apache.wicket.request.cycle.RequestCycle.execute(
> > > RequestCycle.java:261)
> > > at
> > > org.apache.wicket.request.cycle.RequestCycle.
> > processRequest(RequestCycle.
> > > java:218)
> > > at
> > > org.apache.wicket.request.cycle.RequestCycle.processRequestAndDetach(
> > > RequestCycle.java:289)
> > > at
> > > org.apache.wicket.protocol.http.WicketFilter.processRequestCycle(
> > > WicketFilter.java:259)
> > > at
> > > org.apache.wicket.protocol.http.WicketFilter.
> > processRequest(WicketFilter.
> > > java:201)
> > > at
> > > org.apache.wicket.protocol.http.WicketFilter.doFilter(
> > > WicketFilter.java:282)
> > > at
> > > org.eclipse.jetty.servlet.ServletHandler$CachedChain.
> > > doFilter(ServletHandler.java:1653)
> > > at
> > > hub.app.servlet.RelativeUrlFilter.doFilter(RelativeUrlFilter.java:54)
> > > at
> > > org.eclipse.jetty.servlet.ServletHandler$CachedChain.
> > > doFilter(ServletHandler.java:1653)
> > > at
> > > com.wideplay.warp.persist.PersistenceFilter$3.run(
> > > PersistenceFilter.java:141)
> > > at
> > > com.wideplay.warp.persist.internal.Lifecycles.
> > > failEarlyAndLeaveNoOneBehind(Lifecycles.java:29)
> > > at
> > > com.wideplay.warp.persist.PersistenceFilter.doFilter(
> > > PersistenceFilter.java:155)
> > > at
> > > org.eclipse.jetty.servlet.ServletHandler$CachedChain.
> > > doFilter(ServletHandler.java:1645)
> > > at
> > > org.eclipse.jetty.servlet.ServletHandler.doHandle(
> > ServletHandler.java:564)
> > > at
> > > org.eclipse.jetty.server.handler.ScopedHandler.handle(
> > > ScopedHandler.java:143)
> > > at
> > > org.eclipse.jetty.security.SecurityHandler.handle(
> > > SecurityHandler.java:578)
> > > at
> > > org.eclipse.jetty.server.session.SessionHandler.
> > > doHandle(SessionHandler.java:221)
> > > at
> > > org.eclipse.jetty.server.handler.ContextHandler.
> > > doHandle(ContextHandler.java:)
> > > at
> > > org.eclipse.jetty.servlet.ServletHandler.doScope(
> > ServletHandler.java:498)
> > > at
> > > org.eclipse.jetty.server.session.SessionHandler.
> > > doScope(SessionHandler.java:183)
> > > at
> > > org.eclipse.jetty.server.handler.ContextHandler.
> > > doScope(ContextHandler.java:1045)
> > > at
> > > org.eclipse.jetty.server.handler.ScopedHandler.handle(
> > > ScopedHandler.java:141)
> > > at
> > > org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(
> > > ContextHandlerCollection.java:199)
> > > at
> > > org.eclipse.jetty.server.handler.HandlerCollection.
> > > handle(HandlerCollection.java:109)
> > > at
> > > org.eclipse.jetty.server.handler.HandlerWrapper.handle(
> > > HandlerWrapper.java:98)
> >

Re: NPE in org.apache.wicket.request.http.handler.RedirectRequestHandler.respond

[Wayne W]

Still on 6.17.0 Martin. Not had the time/resources to move to 6.18 which I
want because of that replication fix!!

On Tue, Jul 25, 2017 at 7:55 PM, Martin Grigorov 
wrote:

> Which version of Wicket do you use ?
>
> Martin Grigorov
> Wicket Training and Consulting
> https://twitter.com/mtgrigorov
>
> On Tue, Jul 25, 2017 at 5:52 PM, Wayne W 
> wrote:
>
> > Hi,
> >
> > I've got a strange issue I cannot get to the bottom of. Basically we have
> > our app deployed on jetty 9.2.1 with apache 2.4 in front. If I make calls
> > to stateless pages its all good. However as soon as I try to make a call
> to
> > a stateful page it does a 302 to the login page for our app, but then
> just
> > gets stuck in a 302 loop redirection loop. Looking at the server logs its
> > full of this with no other exception - each track trace corresponds to
> > another 302 redirect. Each redirect is trying to get to our login page:
> >
> >
> > 2017-07-25 14:40:18,989 ERROR -
> > org.apache.wicket.DefaultExceptionMapper.internalMap(
> > DefaultExceptionMapper.java:129)
> > 129 DefaultExceptionMapper - Unexpected error occurred
> > java.lang.NullPointerException
> > at
> > org.apache.wicket.request.http.handler.RedirectRequestHandler.respond(
> > RedirectRequestHandler.java:99)
> > at
> > org.apache.wicket.request.cycle.RequestCycle$HandlerExecutor.respond(
> > RequestCycle.java:862)
> > at
> > org.apache.wicket.request.RequestHandlerStack.execute(
> > RequestHandlerStack.java:64)
> > at
> > org.apache.wicket.request.RequestHandlerStack.execute(
> > RequestHandlerStack.java:93)
> > at
> > org.apache.wicket.request.cycle.RequestCycle.execute(
> > RequestCycle.java:261)
> > at
> > org.apache.wicket.request.cycle.RequestCycle.
> processRequest(RequestCycle.
> > java:218)
> > at
> > org.apache.wicket.request.cycle.RequestCycle.processRequestAndDetach(
> > RequestCycle.java:289)
> > at
> > org.apache.wicket.protocol.http.WicketFilter.processRequestCycle(
> > WicketFilter.java:259)
> > at
> > org.apache.wicket.protocol.http.WicketFilter.
> processRequest(WicketFilter.
> > java:201)
> > at
> > org.apache.wicket.protocol.http.WicketFilter.doFilter(
> > WicketFilter.java:282)
> > at
> > org.eclipse.jetty.servlet.ServletHandler$CachedChain.
> > doFilter(ServletHandler.java:1653)
> > at
> > hub.app.servlet.RelativeUrlFilter.doFilter(RelativeUrlFilter.java:54)
> > at
> > org.eclipse.jetty.servlet.ServletHandler$CachedChain.
> > doFilter(ServletHandler.java:1653)
> > at
> > com.wideplay.warp.persist.PersistenceFilter$3.run(
> > PersistenceFilter.java:141)
> > at
> > com.wideplay.warp.persist.internal.Lifecycles.
> > failEarlyAndLeaveNoOneBehind(Lifecycles.java:29)
> > at
> > com.wideplay.warp.persist.PersistenceFilter.doFilter(
> > PersistenceFilter.java:155)
> > at
> > org.eclipse.jetty.servlet.ServletHandler$CachedChain.
> > doFilter(ServletHandler.java:1645)
> > at
> > org.eclipse.jetty.servlet.ServletHandler.doHandle(
> ServletHandler.java:564)
> > at
> > org.eclipse.jetty.server.handler.ScopedHandler.handle(
> > ScopedHandler.java:143)
> > at
> > org.eclipse.jetty.security.SecurityHandler.handle(
> > SecurityHandler.java:578)
> > at
> > org.eclipse.jetty.server.session.SessionHandler.
> > doHandle(SessionHandler.java:221)
> > at
> > org.eclipse.jetty.server.handler.ContextHandler.
> > doHandle(ContextHandler.java:)
> > at
> > org.eclipse.jetty.servlet.ServletHandler.doScope(
> ServletHandler.java:498)
> > at
> > org.eclipse.jetty.server.session.SessionHandler.
> > doScope(SessionHandler.java:183)
> > at
> > org.eclipse.jetty.server.handler.ContextHandler.
> > doScope(ContextHandler.java:1045)
> > at
> > org.eclipse.jetty.server.handler.ScopedHandler.handle(
> > ScopedHandler.java:141)
> > at
> > org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(
> > ContextHandlerCollection.java:199)
> > at
> > org.eclipse.jetty.server.handler.HandlerCollection.
> > handle(HandlerCollection.java:109)
> > at
> > org.eclipse.jetty.server.handler.HandlerWrapper.handle(
> > HandlerWrapper.java:98)
> > at org.eclipse.jetty.server.Server.handle(Server.java:461)
> > at org.eclipse.jetty.server.HttpChannel.handle(
> > HttpChannel.java:284)
> > at
> > org.eclipse.jetty.server.HttpConnection.onFillable(
> > HttpConnection.java:244)
> > at
> > org.eclipse.jetty.io.AbstractConnection$2.run(
> AbstractConnection.java:534)
> > at
> > org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(
> > QueuedThreadPool.java:607)
> > at
> > org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(
> > QueuedThreadPool.java:536)
> > at java.lang.Thread.run(Thread.java:745)
> > 2017-07-25 14:40:19,076 ERROR -
> > org.apache.wicket.DefaultExceptionMapper.internalMap(
> > DefaultExceptionMap