Thanks, Emond!
https://issues.apache.org/jira/browse/WICKET-5832
Martin Grigorov
Wicket Training and Consulting
https://twitter.com/mtgrigorov
On Mon, Feb 9, 2015 at 10:50 AM, Emond Papegaaij emond.papega...@topicus.nl
wrote:
Hi Martin,
Unfortunately, there is no way to check if a certain
Hi,
In https://issues.apache.org/jira/browse/WICKET-5833 I propose to add a new
method to
org.apache.wicket.protocol.ws.api.registry.IWebSocketConnectionRegistry
to return all we bsocket connections per user session.
This is an API break - with
My best solution would be to discuss API breaks on a case by case basis.
If breaks happen on a minor part of our API, I am not against them,
even if they are late in the game. Say if they typically would break 1
class or at most 10 classes in a large application (100+ pages). So
IChoiceRenderer
It also depends on how much work it would be to implement the interface method.
Martijn
On Mon, Feb 9, 2015 at 10:43 AM, Martijn Dashorst
martijn.dasho...@gmail.com wrote:
My best solution would be to discuss API breaks on a case by case basis.
If breaks happen on a minor part of our API, I
This vote is to release Apache Wicket 1.5.13
Git repo
http://git-wip-us.apache.org/repos/asf/wicket.git
Branch name
build/wicket-1.5.13
Archived and signed Git repo
https://dist.apache.org/repos/dist/dev/wicket/1.5.13/
Maven staging repo
Reading the comments from this discussion and considering that we are
focused on releasing Wicket 7 as soon as possible, I suggest to postpone
the decommission to Wicket 8. Java 8 provides the means to keep the
useful part of datetime while moving away the yui stuff.
On Mon, Feb 9, 2015 at
Thank you Martin! I was able to get it to work really simply with setting
the following in my WebApplication:
setSessionStoreProvider
setPageManagerProvider
The implementations just passively passed and retrieved the data to and
from my Redis server.
Thanks,
Bryan
On Mon, Feb 9, 2015 at 3:32
Hi,
The other day I've helped Sebastien with the task he explained at
http://markmail.org/message/mmviy6tsv47g7rhr.
The problem we hit is that when an non-http thread needs to write to Native
WebSockets connection it fails at Weld check for active context
at
Thanks!
On Mon, Feb 9, 2015 at 9:06 PM, Martin Grigorov mgrigo...@apache.org
wrote:
Hi,
WicketStuff core 6.19.0 based on Apache Wicket 6.19.0 is released and
available at Maven Central.
The changelog since 6.18.0 is:
cmiles74 (31):
Fixed bad links in the example app
Added
and more thanks!
On Mon, Feb 9, 2015 at 9:02 PM, Martin Grigorov mgrigo...@apache.org
wrote:
Hi,
WicketStuff core 7.0.0-M5 based on Apache Wicket 7.0.0-M5 is released and
available at Maven Central.
The changelog since 7.0.0-M4 is:
cmiles74 (35): (OpenLayerMaps)
Fixed bad links in
Has anyone setup wicket's AuthenticatedWebApplication sessions to use a
distributed memory cache (e.g. memcached, redis)? I would like to make the
sticky sessions fail over to other tomcat's and allow non sticky load
balancers.
For example, I tested with
Hi,
Since I while I want to create an integration with
https://github.com/spring-projects/spring-session but I haven't had the
time (and demand).
The way to do it is to create custom impl of ISessionStore interface.
Otherwise I remember a user in the community successfully using distributed
Oh, well.
Another two years to stay around.
+0
Martin Grigorov
Wicket Training and Consulting
https://twitter.com/mtgrigorov
On Mon, Feb 9, 2015 at 5:11 PM, Andrea Del Bene an.delb...@gmail.com
wrote:
Reading the comments from this discussion and considering that we are
focused on releasing
Hi,
WicketStuff core 7.0.0-M5 based on Apache Wicket 7.0.0-M5 is released and
available at Maven Central.
The changelog since 7.0.0-M4 is:
cmiles74 (35): (OpenLayerMaps)
Fixed bad links in the example app
Turned off verbosity for Maven compiler plugin
Added Travis CI status
Hi,
WicketStuff core 6.19.0 based on Apache Wicket 6.19.0 is released and
available at Maven Central.
The changelog since 6.18.0 is:
cmiles74 (31):
Fixed bad links in the example app
Added Travis CI status image
Fixed bug in tile variable declaration
Merge branch
+1 to release
Martin Grigorov
Wicket Training and Consulting
https://twitter.com/mtgrigorov
On Mon, Feb 9, 2015 at 12:03 PM, Martin Grigorov mgrigo...@apache.org
wrote:
This vote is to release Apache Wicket 1.5.13
Git repo
http://git-wip-us.apache.org/repos/asf/wicket.git
Branch name
So what's the intended last phase before we announce 7.0 and freeze the API?
On Mon, Feb 9, 2015 at 8:26 AM, Martin Grigorov mgrigo...@apache.org
wrote:
There won't be RC phase.
There is no difference between RC1 and 7.0.0.
Both do not allow API breaks. Fixing bugs and adding
I'd suggest to move -datetime to WicketStuff and add a ticket to improve
the DateConverter in -utils with timezone support for Wicket 8.
Sooner 7.0.0 is released, sooner we can start working on Wicket 8 that will
depend on JDK 8.
WDYT ?
Martin Grigorov
Wicket Training and Consulting
move -datetime to WicketStuff ... WDYT ?
Only if we deprecate all classes in that module: wicketstuff isn't a
waste bin for things we don't like/support any more.
Regards
Sven
On 09.02.2015 14:55, Martin Grigorov wrote:
I'd suggest to move -datetime to WicketStuff and add a ticket to
Sounds like a plan...
Martijn
On Mon, Feb 9, 2015 at 2:55 PM, Martin Grigorov mgrigo...@apache.org wrote:
I'd suggest to move -datetime to WicketStuff and add a ticket to improve
the DateConverter in -utils with timezone support for Wicket 8.
Sooner 7.0.0 is released, sooner we can start
+1 release 1.5.13
Regards
Sven
On 09.02.2015 11:03, Martin Grigorov wrote:
This vote is to release Apache Wicket 1.5.13
Git repo
http://git-wip-us.apache.org/repos/asf/wicket.git
Branch name
build/wicket-1.5.13
Archived and signed Git repo
Maybe I'm wrong but it doesn't look an heavy changeI think it falls
in the acceptable category described by Martijn.
My best solution would be to discuss API breaks on a case by case basis.
If breaks happen on a minor part of our API, I am not against them,
even if they are late in the
There won't be RC phase.
There is no difference between RC1 and 7.0.0.
Both do not allow API breaks. Fixing bugs and adding features/improvements
are the same for both. So there is no point in releasing candidates.
Martin Grigorov
Wicket Training and Consulting
https://twitter.com/mtgrigorov
On
I'd rather upgrade to java 8 than depend on jodatime in core. Jodatime
is a stopgap until java 8 gains enough traction.
Martijn
On Mon, Feb 9, 2015 at 2:18 PM, Andrea Del Bene an.delb...@gmail.com wrote:
Sorry, I was mistaken by another pair of namesake classes named
DateConverter
Sorry, I was mistaken by another pair of namesake classes named
DateConverter DateTextField from extensions module uses
DateConverter from utils module, not the one from datetime. So in short,
I agree to decommission datetime and move it as it is to wicketstuff.
The only minor thing I'm
Breaking APIs should be ok until we hit the RC phase - otherwise things
like this wont be able to be changed until Wicket 8.0.
On Mon, Feb 9, 2015 at 4:29 AM, Martin Grigorov mgrigo...@apache.org
wrote:
Hi,
In https://issues.apache.org/jira/browse/WICKET-5833 I propose to add a
new
method
On Mon, Feb 9, 2015 at 4:02 PM, Sven Meier s...@meiers.net wrote:
move -datetime to WicketStuff ... WDYT ?
Only if we deprecate all classes in that module: wicketstuff isn't a waste
bin for things we don't like/support any more.
The main problem is the usage of YUI 2.x for the impl.
I've
I thought that after -M4 will come 7.0.0.
People suggested to release -M5 too...
On Mon, Feb 9, 2015 at 3:52 PM, Nick Pratt nbpr...@gmail.com wrote:
So what's the intended last phase before we announce 7.0 and freeze the
API?
On Mon, Feb 9, 2015 at 8:26 AM, Martin Grigorov
28 matches
Mail list logo
