Re: Plans for Wicket 10 Release
I am looking forward to testing RC1 in several projects. Thank you for moving this forward! On Wed, Jun 7, 2023 at 6:00 AM Martin Grigorov wrote: > On Wed, May 31, 2023 at 7:37 AM Maxim Solodovnik > wrote: > > > Should be fixed with this: https://github.com/apache/wicket/pull/591 :) > > > > If no one has a better solution than I suggest to merge this PR and release > Wicket 10 RC1 > > > > > > > On Tue, 30 May 2023 at 22:16, Maxim Solodovnik > > wrote: > > > > > > > > > > > > from mobile (sorry for typos ;) > > > > > > > > > On Tue, May 30, 2023, 20:05 Jeroen Steenbeeke < > j.steenbeeke...@gmail.com> > > wrote: > > >> > > >> The current wicket-commons-fileupload 10.0.0-M1-SNAPSHOT jar in the > > Apache > > >> snapshots repo duplicates classes from commons-io, Jakarta Servlet and > > >> SLF4J and is triggering my Maven Enforcer's BanDuplicateClasses rule. > > > > > > > > > Sounds interesting > > > Could you share details? :) > > > > > >> > > >> Op za 27 mei 2023 om 21:53 schreef Martin Grigorov < > > mgrigo...@apache.org>: > > >> > > >> > On Sat, May 27, 2023 at 8:18 PM smallufo > wrote: > > >> > > > >> > > Hi > > >> > > Where can I get wicket-10 snapshot ? > > >> > > > > >> > > > >> > > > >> > > > > https://github.com/apache/wicket/blob/master/archetypes/quickstart/src/main/resources/archetype-resources/pom.xml#L175-L186 > > >> > > > >> > I cannot find it in mvnrepository.com ... > > >> > > > >> > I've upgrade all subsystems from javax to jakarta , and spring 5 to > > spring > > >> > 6 > > >> > > But a lot of incompatibility issues are in wicket 9 > > >> > > Since it has no major issues , how about releasing it ASAP ? > > >> > > Thanks. > > >> > > > > >> > > > > >> > > János Cserép 於 2023年5月25日 週四 下午3:51寫道： > > >> > > > > >> > > > Just a thought... > > >> > > > > > >> > > > I've been using Wicket 10 snapshot builds in production for over > > a year > > >> > > now > > >> > > > with latest Spring and Jakarta libs without any major issues, so > > if > > >> > that > > >> > > is > > >> > > > an option for you, go ahead. You can mitigate risks by creating > > release > > >> > > > from a known git rev yourself if your release process does not > > like > > >> > > > SNAPSHOT dependencies. > > >> > > > > > >> > > > j > > >> > > > > > >> > > > > > >> > > > On Thu, 25 May 2023 at 09:15, Tony Tkacik < > > tony.tka...@evolveum.com > > >> > > > .invalid> > > >> > > > wrote: > > >> > > > > > >> > > > > Hi, > > >> > > > > I would like to ask about your timeline / plans regarding > > release of > > >> > > > > Wicket 10? > > >> > > > > > > >> > > > > We are in process of upgrading our open-source project > midPoint > > to > > >> > > latest > > >> > > > > Spring releases and that requires Wicket to be updated to > > version 10 > > >> > > > > in order to support Spring 6. > > >> > > > > > > >> > > > > Thanks, > > >> > > > > Anton Tkacik > > >> > > > > > > >> > > > > > >> > > > > >> > > > >> > > >> > > >> -- > > >> Jeroen Steenbeeke > > > > > > > > -- > > Best regards, > > Maxim > > > > - > > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > > For additional commands, e-mail: users-h...@wicket.apache.org > > > > >
Re: Wicket 10 + Commons FileUpload
Thank you! On Sat, Mar 25, 2023 at 6:05 AM Maxim Solodovnik wrote: > https://github.com/apache/wicket/pull/565 :)) > > On Thu, 23 Mar 2023 at 19:49, Martin Grigorov > wrote: > > > > Hi, > > > > The plan is to copy the fileupload classes in Wicket. > > Do you want to help with a PR ? > > Just create a new Maven module, e.g. wicket-commons-fileupload, and copy > > the Jakarta related classes into org/apache/wicket/commons/fileupload > > package, i.e. to shade them. > > Then update wicket-core to make use of the new module and classes. > > > > On Thu, Mar 23, 2023 at 1:46 PM Greb Lindqvist > > > wrote: > > > > > Hello again, > > > > > > Like you, I've been watching > > > > https://issues.apache.org/jira/projects/FILEUPLOAD/issues/FILEUPLOAD-309 > > > > > > If the FileUpload maintainers continue to be unresponsive, does the > Wicket > > > team have a plan? > > > Are you willing to wait indefinitely or might you commit to an > alternative? > > > If the latter, do you have a feel for when that might be? > > > > > > Thanks for any info. > > > > > > > -- > Best regards, > Maxim > > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > >
Wicket 10 + Commons FileUpload
Hello again, Like you, I've been watching https://issues.apache.org/jira/projects/FILEUPLOAD/issues/FILEUPLOAD-309 If the FileUpload maintainers continue to be unresponsive, does the Wicket team have a plan? Are you willing to wait indefinitely or might you commit to an alternative? If the latter, do you have a feel for when that might be? Thanks for any info.
Re: Spring Boot 3, Wicket 10, Roadmap?
Fantastic! I see your comments on FILEUPLOAD-309. Comments on October 12 make me hopeful that they are planning a release. And thank you for your excellent stewardship of Wicket for so many years. It is much appreciated. On Thu, Oct 20, 2022 at 2:42 AM Martin Grigorov wrote: > Hi, > > On Wed, Oct 19, 2022 at 11:53 PM Greb Lindqvist > wrote: > > > Hello, > > > > My organization has several internal apps running with Spring Boot 2.7 > and > > Wicket 9. We are planning ahead for updating to Spring Boot 3. My > > understanding is that we'll need to wait for Wicket 10. > > > > I haven't tried it but I guess you could use javax-to-jakarta migrator like > https://github.com/apache/tomcat-jakartaee-migration with Wicket 9.x > > > > > > Is there a Wicket Roadmap page? Any guesses for when Wicket 10 milestone > > releases might start appearing? > > > > We track the changes in Wicket 10.x at > https://cwiki.apache.org/confluence/display/WICKET/Migration+to+Wicket+10.0 > . > The major theme is javax->jakarta and Java 11 -> 17. > The only stopper I am aware of is Apache Commons FileUpload - we need a > stable release of 2.x ( > https://issues.apache.org/jira/browse/FILEUPLOAD-309 > ). > Once this issue is resolved we could release a milestone/RC version easily. > > Martin > > > > > > > Thank you > > >
Spring Boot 3, Wicket 10, Roadmap?
Hello, My organization has several internal apps running with Spring Boot 2.7 and Wicket 9. We are planning ahead for updating to Spring Boot 3. My understanding is that we'll need to wait for Wicket 10. Is there a Wicket Roadmap page? Any guesses for when Wicket 10 milestone releases might start appearing? Thank you
Re: Wicket 9 clustered sessions
> Overriding #newPersistentStore() should be enough:
Thank you for your response.
I tried only overriding newPersistentStore() like this
setPageManagerProvider(new DefaultPageManagerProvider(this) {
@Override
protected IPageStore newPersistentStore() {
return new InSessionPageStore(20);
}
});
but get warnings like
WARN o.a.w.p.AsynchronousPageStore - Delegated page store
'org.apache.wicket.pageStore.InSessionPageStore' can not be asynchronous
Adding this fixes the warning
getStoreSettings().setAsynchronous(false);
but looking at the DefaultPageManagerProvider chain:
RequestPageStore -> CachingPageStore -> SerializingPageStore
-> AsynchronousPageStore -> CryptingPageStore -> DiskPageStore
CachingPageStore wraps an InSessionPageStore of its own but I'm thinking
that is not useful when clustering - especially since I'm
using DeflatedJavaSerializer and want it invoked before storing in the
session. For clustering, maybe this makes more sense (assuming using
something like Spring Session)
RequestPageStore -> SerializingPageStore -> CryptingPageStore
-> InSessionPageStore
It seems like this does what I want but I need to test more.
setPageManagerProvider(new DefaultPageManagerProvider(this) {
@Override
protected IPageStore newPersistentStore() {
return new InSessionPageStore(20);
}
@Override
protected IPageStore newCachingStore(IPageStore pageStore) {
return pageStore;
}
@Override
protected IPageStore newAsynchronousStore(IPageStore pageStore)
{
return pageStore;
}
});
Might this clustered use-case be common enough to justify adding another
IPageManagerProvider implementation to Wicket with default behavior more
appropriate for clustering?
Thanks again
On Tue, Jan 19, 2021 at 11:57 AM Sven Meier wrote:
> Hi,
>
> > Is it helpful if I add documentation issues to Wicket Jira?
>
> pull-requests are always preferred :P
>
> >
>
> https://ci.apache.org/projects/wicket/guide/9.x/single.html#_httpsessiondatastore
>
>
> I will take care of this.
>
> >For Wicket 9 I'm overriding DefaultPageManagerProvider like below. Is
> that
> > a good replacement for my Wicket 8 code?
>
> Overriding #newPersistentStore() should be enough:
>
>@Override
>protected IPageStore newPersistentStore() {
> return new InSessionPageStore(20);
>}
>
> >Wicket alive and well! I've been using it since 1.3 :)
>
> Thanks for reporting back.
>
> Regards
> Sven
>
> On 19.01.21 16:02, Greb Lindqvist wrote:
> > Hello everyone,
> >
> > I'm updating an application from Wicket 8 to Wicket 9 and see that
> > IDataStore has been removed. I think the documentation needs to be
> updated
> > here
> >
> https://ci.apache.org/projects/wicket/guide/9.x/single.html#_httpsessiondatastore
> > Is it helpful if I add documentation issues to Wicket Jira?
> >
> > My application uses
> > https://spring.io/projects/spring-session-data-redis
> > so it can be clustered.
> >
> > My Wicket 8 code is like
> > setSessionStoreProvider(HttpSessionStore::new);
> >
> > setPageManagerProvider(new DefaultPageManagerProvider(this) {
> > @Override
> > protected IDataStore newDataStore() {
> > return new HttpSessionDataStore(getPageManagerContext(),
> > new PageNumberEvictionStrategy(20));
> > }
> > });
> >
> > For Wicket 9 I'm overriding DefaultPageManagerProvider like below. Is
> that
> > a good replacement for my Wicket 8 code? It seems to mostly work but I'm
> > seeing slight weirdness that doesn't happen in Wicket 8. If
> > overriding DefaultPageManagerProvider is the correct approach, it would
> be
> > helpful to mention it in the migration guide with a pointer to the
> updated
> > documentation.
> >
> > Thanks to everyone for keeping Wicket alive and well! I've been using it
> > since 1.3 :)
> >
> > setPageManagerProvider(new DefaultPageManagerProvider(this) {
> > @Override
> > public IPageManager get()
> > {
> > IPageStore store = newPersistentStore();
> > store = newSerializingStore(store);
> > store = newRequestStore(store);
> > return new PageManager(store);
> > }
> >
> > @Override
> > protected IPageStore newPersistentStore() {
> > return new InSessionPageStore(20);
> > }
> > });
> >
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>
Wicket 9 clustered sessions
Hello everyone,
I'm updating an application from Wicket 8 to Wicket 9 and see that
IDataStore has been removed. I think the documentation needs to be updated
here
https://ci.apache.org/projects/wicket/guide/9.x/single.html#_httpsessiondatastore
Is it helpful if I add documentation issues to Wicket Jira?
My application uses
https://spring.io/projects/spring-session-data-redis
so it can be clustered.
My Wicket 8 code is like
setSessionStoreProvider(HttpSessionStore::new);
setPageManagerProvider(new DefaultPageManagerProvider(this) {
@Override
protected IDataStore newDataStore() {
return new HttpSessionDataStore(getPageManagerContext(),
new PageNumberEvictionStrategy(20));
}
});
For Wicket 9 I'm overriding DefaultPageManagerProvider like below. Is that
a good replacement for my Wicket 8 code? It seems to mostly work but I'm
seeing slight weirdness that doesn't happen in Wicket 8. If
overriding DefaultPageManagerProvider is the correct approach, it would be
helpful to mention it in the migration guide with a pointer to the updated
documentation.
Thanks to everyone for keeping Wicket alive and well! I've been using it
since 1.3 :)
setPageManagerProvider(new DefaultPageManagerProvider(this) {
@Override
public IPageManager get()
{
IPageStore store = newPersistentStore();
store = newSerializingStore(store);
store = newRequestStore(store);
return new PageManager(store);
}
@Override
protected IPageStore newPersistentStore() {
return new InSessionPageStore(20);
}
});
