Re: [ANNOUNCE] Apache Wicket jQuery UI 8.0.0-M5 Released

2017-03-30 Thread Maxim Solodovnik
Thanks a lot for the release Sebastien!
I just have checked Charts demos at
http://www.7thweb.net/wicket-jquery-ui/kendo/chart/LineChartPage?6
All charts seems to be broken :(

On Fri, Mar 31, 2017 at 1:04 AM, Sebastien  wrote:

> Dear Wicket jQuery UI users,
>
> Wicket jQuery UI 8.0.0-M5 based on Apache Wicket 8.0.0-M5 is now released.
>
> *Changelog:*
> https://github.com/sebfz1/wicket-jquery-ui/releases/tag/
> wicket-jquery-ui-8.0.0-M5
>
> *Maven dependencies:*
>
> 
>
> 
> com.googlecode.wicket-jquery-ui
> wicket-jquery-ui
> 8.0.0-M5
> 
>
> 
> com.googlecode.wicket-jquery-ui
> wicket-jquery-ui-theme-base
> 8.0.0-M5
> 
>
> 
>
> 
> com.googlecode.wicket-jquery-ui
> wicket-kendo-ui
> 8.0.0-M5
> 
>
> 
> com.googlecode.wicket-jquery-ui
> wicket-kendo-ui-theme-default
> 8.0.0-M5
> 
>
> If you have any *question*, feel free to ask in the forum:
> http://groups.google.com/group/wicket-jquery-ui/
>
> If you notice an *issue*, please report it here:
> https://github.com/sebfz1/wicket-jquery-ui/issues
>
> Enjoy! :)
>



-- 
WBR
Maxim aka solomax


Re: Quick Start Wicket version

2017-03-30 Thread Maxim Solodovnik
Thanks a lot for the quick fix Andrea :)


On Fri, Mar 31, 2017 at 3:13 AM, Andrea Del Bene 
wrote:

> Hi,
>
> Maven resource filtering  caused the corruption of the keystore file. Now
> it should be fixed and snapshot quickstarts should run correctly.
>
> Andrea.
>
>
> On 30/03/2017 15:18, Maxim Solodovnik wrote:
>
>> sure:
>>
>> Steps:
>> 1) go to create quickstart page [1]
>> 2) choose 8.0.0-SNAPSHOT
>> 3) copy/create project [2]
>> 4) cd myproject
>> 5) mvn jetty:run
>> Result: Stack trace [3]
>>
>> Workaround: remove all https/ssl related jetty components
>>
>> *[1]* http://wicket.apache.org/start/quickstart.html
>> *[2]* mvn archetype:generate -DarchetypeGroupId=org.apache.wicket
>> -DarchetypeArtifactId=wicket-archetype-quickstart
>> -DarchetypeVersion=8.0.0-SNAPSHOT -DgroupId=com.mycompany
>> -DartifactId=myproject -DarchetypeRepository=
>> https://repository.apache.org/content/repositories/snapshots/
>> -DinteractiveMode=false
>> *[3] *
>> [ERROR] Failed to execute goal
>> org.eclipse.jetty:jetty-maven-plugin:9.4.3.v20170317:run (default-cli) on
>> project myproject: Failure: Invalid keystore format -> [Help 1]
>> [ERROR]
>> [ERROR] To see the full stack trace of the errors, re-run Maven with the
>> -e
>> switch.
>> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
>> [ERROR]
>> [ERROR] For more information about the errors and possible solutions,
>> please read the following articles:
>> [ERROR] [Help 1]
>> http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException
>> Exception in thread "Thread-1" java.lang.NoClassDefFoundError:
>> org/eclipse/jetty/io/ManagedSelector$CloseEndPoints
>> at org.eclipse.jetty.io.ManagedSelector.doStop(ManagedSelector.java:135)
>> at
>> org.eclipse.jetty.util.component.AbstractLifeCycle.stop(
>> AbstractLifeCycle.java:89)
>> at
>> org.eclipse.jetty.util.component.ContainerLifeCycle.stop(
>> ContainerLifeCycle.java:142)
>> at
>> org.eclipse.jetty.util.component.ContainerLifeCycle.doStop(
>> ContainerLifeCycle.java:160)
>> at org.eclipse.jetty.io.SelectorManager.doStop(SelectorManager.java:257)
>> at
>> org.eclipse.jetty.util.component.AbstractLifeCycle.stop(
>> AbstractLifeCycle.java:89)
>> at
>> org.eclipse.jetty.util.component.ContainerLifeCycle.stop(
>> ContainerLifeCycle.java:142)
>> at
>> org.eclipse.jetty.util.component.ContainerLifeCycle.doStop(
>> ContainerLifeCycle.java:160)
>> at
>> org.eclipse.jetty.client.AbstractHttpClientTransport.doStop(
>> AbstractHttpClientTransport.java:87)
>> at
>> org.eclipse.jetty.util.component.AbstractLifeCycle.stop(
>> AbstractLifeCycle.java:89)
>> at
>> org.eclipse.jetty.util.component.ContainerLifeCycle.stop(
>> ContainerLifeCycle.java:142)
>> at
>> org.eclipse.jetty.util.component.ContainerLifeCycle.doStop(
>> ContainerLifeCycle.java:160)
>> at org.eclipse.jetty.client.HttpClient.doStop(HttpClient.java:254)
>> at
>> org.eclipse.jetty.util.component.AbstractLifeCycle.stop(
>> AbstractLifeCycle.java:89)
>> at
>> org.eclipse.jetty.util.component.ContainerLifeCycle.stop(
>> ContainerLifeCycle.java:142)
>> at
>> org.eclipse.jetty.util.component.ContainerLifeCycle.doStop(
>> ContainerLifeCycle.java:160)
>> at
>> org.eclipse.jetty.websocket.client.WebSocketClient.doStop(We
>> bSocketClient.java:376)
>> at
>> org.eclipse.jetty.util.component.AbstractLifeCycle.stop(
>> AbstractLifeCycle.java:89)
>> at
>> org.eclipse.jetty.util.component.ContainerLifeCycle.stop(
>> ContainerLifeCycle.java:142)
>> at
>> org.eclipse.jetty.util.component.ContainerLifeCycle.doStop(
>> ContainerLifeCycle.java:160)
>> at
>> org.eclipse.jetty.websocket.jsr356.ClientContainer.doStop(Cl
>> ientContainer.java:214)
>> at
>> org.eclipse.jetty.util.component.AbstractLifeCycle.stop(
>> AbstractLifeCycle.java:89)
>> at org.eclipse.jetty.util.thread.ShutdownThread.run(ShutdownThr
>> ead.java:138)
>> Caused by: java.lang.ClassNotFoundException:
>> org.eclipse.jetty.io.ManagedSelector$CloseEndPoints
>> at
>> org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy.
>> loadClass(SelfFirstStrategy.java:50)
>> at
>> org.codehaus.plexus.classworlds.realm.ClassRealm.unsynchroni
>> zedLoadClass(ClassRealm.java:271)
>> at
>> org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(
>> ClassRealm.java:247)
>> at
>> org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(
>> ClassRealm.java:239)
>> ... 23 more
>>
>>
>>
>> On Thu, Mar 30, 2017 at 8:01 PM, Andrea Del Bene 
>> wrote:
>>
>> Hi Maxim,
>>>
>>> can you provide more details about the problem with jetty:run?
>>>
>>> thank you.
>>>
>>> On Thu, Mar 30, 2017 at 2:38 PM, Maxim Solodovnik 
>>> wrote:
>>>
>>> Another report:

 Latest wicket version still M4
 Project created using latest 8.0.0-SNAPSHOT is not runnable using

>>> jetty:run
>>>
 On Thu, Mar 30, 2017 at 7:31 PM, Andrea Del Bene 
 wrote:

> It sounds like a subliminal message :-)
>
> On Thu, Mar 

Re: ComponentNotFoundException and Clustering failover

2017-03-30 Thread Wayne W
Please ignore my last email I have done a lot more debugging and I *think*
I understand why replication does not work for us:


Whenever a stateful pages is used (touched) the SessionEntry is updated,
> i.e. the page is put into it.
> The SessionEntry is stored as an attribute in the HTTP Session.
> The web container has logic to detect if the HTTP session has been updated
> in a request and if it was then it replicates the whole session to the
> other nodes.
> Once the session is replicated it is deserialized. Here
> SessionEntry#readObject() comes to play. It reads the pages from the
> SessionEntry and stores them into the disk (via IDiskStore).
> So the stateful pages should be available in the disks of all nodes.
> Stateless pages are always recreated from scratch, so they are not
> replicated.


I think this is a little wrong. Yes the SessionEntry in stored as an
attribute in the http session and is replicated. However the pages in the
SessionEntry cache are not replicated as they are transient.

private transient List sessionCache;

private transient List afterReadObject

Therefore the pages are *not* deserialised as you say. The only time
SessionEntry#readObject()
comes to play (at least with Tomcat) is when a node is first brought up and
the daltamanager replicates ALL sessions across, at this point all the
current SessionEntry's in the other nodes http sessions are written across.
After this is done SessionEntry#readObject() is not called anymore. Any new
pages/updates on the original instance are not replicated across (only the
sessionId in the SessionEntry).

This means any new pages created on the old instance (after the new
instance has started up) are not available in the http session or the
second level page store on the new instance.
Therefore when the old instance in shut down the user is load balanced to
the new instance. At this point the link in the page Wicket is looking for
does not exist in the SessionEntry cache or the PageStore so it creates the
page and looks for the component/link.

This causes a ComponentNotFoundException for us because the links are
either in a DataView which is never rendered so does not exist, or the
other links are actually added to the page in an Ajax request and again
because the page is not rendered are not there, Wicket then throws the
exception and it appears to the user the session is lost.

This is at least what I am observing. I can provide a Quick start to
demonstrate if needed.

many thanks for you time thus far.


On Thu, Mar 30, 2017 at 4:29 PM, Wayne W 
wrote:

>
>
> On Thu, Mar 30, 2017 at 4:09 PM, Martin Grigorov 
> wrote:
>
>>
>>
>> Whenever a stateful pages is used (touched) the SessionEntry is updated,
>> i.e. the page is put into it.
>>
>
> Yes I can see that happening in PageStoreManager.storeTouchedPages()
>
>
>> The SessionEntry is stored as an attribute in the HTTP Session.
>>
>
> I'm not seeing this. In the wicket.Session class there is line :
>
> private transient ISessionStore sessionStore;
>
> Which is loaded from the Application each request. The SessionStore
> contains the SessionEntry's no???
>
>
>
>> The web container has logic to detect if the HTTP session has been updated
>> in a request and if it was then it replicates the whole session to the
>> other nodes.
>>
>
> Yes I'm seeing the http session replicated no issues.
>
>
>> Once the session is replicated it is deserialized. Here
>> SessionEntry#readObject() comes to play. It reads the pages from the
>> SessionEntry and stores them into the disk (via IDiskStore).
>> So the stateful pages should be available in the disks of all nodes.
>> Stateless pages are always recreated from scratch, so they are not
>> replicated.
>>
>
>
> If this is the case why is wicket saying this page is stateless as the
> SessionEntry is never replicated across?:
>
>
>
> public class HomePage extends WebPage {
>
> private static final long serialVersionUID = 1L;
>
>
> public HomePage() {
>
> super();
>
>
> Session s= Session.get();
>
> s.bind();
>
> Integer i = (Integer)s.getAttribute("foo");
>
> if (i == null) {
>
> i = new Integer(0);
>
> }
>
> i++;
>
> s.setAttribute("foo",i);
>
> add(new Label("version", (Integer)s.getAttribute("foo")));
>
>
> add(new Link("link1") {
>
> @Override
>
> public void onClick()
>
> {
>
> setResponsePage(new NextPage());
>
> }
>
> });
>
> add(new Link("link2") {
>
> @Override
>
> public void onClick()
>
> {
>
> setResponsePage(new HomePage());
>
> }
>
> });
>
> add(new AbstractDefaultAjaxBehavior() {
>
> @Override
>
> protected void respond(AjaxRequestTarget target) {
>
> getSession().setAttribute("someKey", UUID.randomUUID().toString());
>
> System.out.println("SLEEEPING");
>
> try {
>
> Thread.sleep(3000);
>
> }catch(Exception e) {
>
> }
>
> System.out.println("DONE");
>
> }
>
> @Override
>
> public void renderHead(Component component, IHeaderResponse response) {
>
> super.renderHead(component, response);
>
> 

Re: Quick Start Wicket version

2017-03-30 Thread Andrea Del Bene

Hi,

Maven resource filtering  caused the corruption of the keystore file. 
Now it should be fixed and snapshot quickstarts should run correctly.


Andrea.


On 30/03/2017 15:18, Maxim Solodovnik wrote:

sure:

Steps:
1) go to create quickstart page [1]
2) choose 8.0.0-SNAPSHOT
3) copy/create project [2]
4) cd myproject
5) mvn jetty:run
Result: Stack trace [3]

Workaround: remove all https/ssl related jetty components

*[1]* http://wicket.apache.org/start/quickstart.html
*[2]* mvn archetype:generate -DarchetypeGroupId=org.apache.wicket
-DarchetypeArtifactId=wicket-archetype-quickstart
-DarchetypeVersion=8.0.0-SNAPSHOT -DgroupId=com.mycompany
-DartifactId=myproject -DarchetypeRepository=
https://repository.apache.org/content/repositories/snapshots/
-DinteractiveMode=false
*[3] *
[ERROR] Failed to execute goal
org.eclipse.jetty:jetty-maven-plugin:9.4.3.v20170317:run (default-cli) on
project myproject: Failure: Invalid keystore format -> [Help 1]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e
switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions,
please read the following articles:
[ERROR] [Help 1]
http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException
Exception in thread "Thread-1" java.lang.NoClassDefFoundError:
org/eclipse/jetty/io/ManagedSelector$CloseEndPoints
at org.eclipse.jetty.io.ManagedSelector.doStop(ManagedSelector.java:135)
at
org.eclipse.jetty.util.component.AbstractLifeCycle.stop(AbstractLifeCycle.java:89)
at
org.eclipse.jetty.util.component.ContainerLifeCycle.stop(ContainerLifeCycle.java:142)
at
org.eclipse.jetty.util.component.ContainerLifeCycle.doStop(ContainerLifeCycle.java:160)
at org.eclipse.jetty.io.SelectorManager.doStop(SelectorManager.java:257)
at
org.eclipse.jetty.util.component.AbstractLifeCycle.stop(AbstractLifeCycle.java:89)
at
org.eclipse.jetty.util.component.ContainerLifeCycle.stop(ContainerLifeCycle.java:142)
at
org.eclipse.jetty.util.component.ContainerLifeCycle.doStop(ContainerLifeCycle.java:160)
at
org.eclipse.jetty.client.AbstractHttpClientTransport.doStop(AbstractHttpClientTransport.java:87)
at
org.eclipse.jetty.util.component.AbstractLifeCycle.stop(AbstractLifeCycle.java:89)
at
org.eclipse.jetty.util.component.ContainerLifeCycle.stop(ContainerLifeCycle.java:142)
at
org.eclipse.jetty.util.component.ContainerLifeCycle.doStop(ContainerLifeCycle.java:160)
at org.eclipse.jetty.client.HttpClient.doStop(HttpClient.java:254)
at
org.eclipse.jetty.util.component.AbstractLifeCycle.stop(AbstractLifeCycle.java:89)
at
org.eclipse.jetty.util.component.ContainerLifeCycle.stop(ContainerLifeCycle.java:142)
at
org.eclipse.jetty.util.component.ContainerLifeCycle.doStop(ContainerLifeCycle.java:160)
at
org.eclipse.jetty.websocket.client.WebSocketClient.doStop(WebSocketClient.java:376)
at
org.eclipse.jetty.util.component.AbstractLifeCycle.stop(AbstractLifeCycle.java:89)
at
org.eclipse.jetty.util.component.ContainerLifeCycle.stop(ContainerLifeCycle.java:142)
at
org.eclipse.jetty.util.component.ContainerLifeCycle.doStop(ContainerLifeCycle.java:160)
at
org.eclipse.jetty.websocket.jsr356.ClientContainer.doStop(ClientContainer.java:214)
at
org.eclipse.jetty.util.component.AbstractLifeCycle.stop(AbstractLifeCycle.java:89)
at org.eclipse.jetty.util.thread.ShutdownThread.run(ShutdownThread.java:138)
Caused by: java.lang.ClassNotFoundException:
org.eclipse.jetty.io.ManagedSelector$CloseEndPoints
at
org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy.loadClass(SelfFirstStrategy.java:50)
at
org.codehaus.plexus.classworlds.realm.ClassRealm.unsynchronizedLoadClass(ClassRealm.java:271)
at
org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:247)
at
org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:239)
... 23 more



On Thu, Mar 30, 2017 at 8:01 PM, Andrea Del Bene 
wrote:


Hi Maxim,

can you provide more details about the problem with jetty:run?

thank you.

On Thu, Mar 30, 2017 at 2:38 PM, Maxim Solodovnik 
wrote:


Another report:

Latest wicket version still M4
Project created using latest 8.0.0-SNAPSHOT is not runnable using

jetty:run

On Thu, Mar 30, 2017 at 7:31 PM, Andrea Del Bene 
wrote:

It sounds like a subliminal message :-)

On Thu, Mar 30, 2017 at 11:13 AM, Martin Grigorov <

mgrigo...@apache.org>

wrote:


Hi,

Thanks for the report!
I've fixed this few months ago:
https://github.com/apache/wicket/commit/

86f7cb04020c5298e3408aea56c94e

744afed155
Maybe it is time for 7.7.0. 7.6.0 has been released 3 months ago!

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

On Thu, Mar 30, 2017 at 10:49 AM, Peter Henderson <
peter.hender...@starjar.com> wrote:


Hi all.

I've just created a quick start from [1] using [2]

The resulting project (pom.xml) is using
7.5.0-SNAPSHOT

Probably something 

[ANNOUNCE] Apache Wicket jQuery UI 8.0.0-M5 Released

2017-03-30 Thread Sebastien
Dear Wicket jQuery UI users,

Wicket jQuery UI 8.0.0-M5 based on Apache Wicket 8.0.0-M5 is now released.

*Changelog:*
https://github.com/sebfz1/wicket-jquery-ui/releases/tag/wicket-jquery-ui-8.0.0-M5

*Maven dependencies:*




com.googlecode.wicket-jquery-ui
wicket-jquery-ui
8.0.0-M5



com.googlecode.wicket-jquery-ui
wicket-jquery-ui-theme-base
8.0.0-M5





com.googlecode.wicket-jquery-ui
wicket-kendo-ui
8.0.0-M5



com.googlecode.wicket-jquery-ui
wicket-kendo-ui-theme-default
8.0.0-M5


If you have any *question*, feel free to ask in the forum:
http://groups.google.com/group/wicket-jquery-ui/

If you notice an *issue*, please report it here:
https://github.com/sebfz1/wicket-jquery-ui/issues

Enjoy! :)


Re: ComponentNotFoundException and Clustering failover

2017-03-30 Thread Wayne W
On Thu, Mar 30, 2017 at 4:09 PM, Martin Grigorov 
wrote:

>
>
> Whenever a stateful pages is used (touched) the SessionEntry is updated,
> i.e. the page is put into it.
>

Yes I can see that happening in PageStoreManager.storeTouchedPages()


> The SessionEntry is stored as an attribute in the HTTP Session.
>

I'm not seeing this. In the wicket.Session class there is line :

private transient ISessionStore sessionStore;

Which is loaded from the Application each request. The SessionStore
contains the SessionEntry's no???



> The web container has logic to detect if the HTTP session has been updated
> in a request and if it was then it replicates the whole session to the
> other nodes.
>

Yes I'm seeing the http session replicated no issues.


> Once the session is replicated it is deserialized. Here
> SessionEntry#readObject() comes to play. It reads the pages from the
> SessionEntry and stores them into the disk (via IDiskStore).
> So the stateful pages should be available in the disks of all nodes.
> Stateless pages are always recreated from scratch, so they are not
> replicated.
>


If this is the case why is wicket saying this page is stateless as the
SessionEntry is never replicated across?:



public class HomePage extends WebPage {

private static final long serialVersionUID = 1L;


public HomePage() {

super();


Session s= Session.get();

s.bind();

Integer i = (Integer)s.getAttribute("foo");

if (i == null) {

i = new Integer(0);

}

i++;

s.setAttribute("foo",i);

add(new Label("version", (Integer)s.getAttribute("foo")));


add(new Link("link1") {

@Override

public void onClick()

{

setResponsePage(new NextPage());

}

});

add(new Link("link2") {

@Override

public void onClick()

{

setResponsePage(new HomePage());

}

});

add(new AbstractDefaultAjaxBehavior() {

@Override

protected void respond(AjaxRequestTarget target) {

getSession().setAttribute("someKey", UUID.randomUUID().toString());

System.out.println("SLEEEPING");

try {

Thread.sleep(3000);

}catch(Exception e) {

}

System.out.println("DONE");

}

@Override

public void renderHead(Component component, IHeaderResponse response) {

super.renderHead(component, response);

String js = "(" + getCallbackFunction().toString() +")();";

response.render(OnDomReadyHeaderItem.forScript(js));

}

});

// TODO Add your page's components here


}

}



Sorry for all these questions but I must get to the bottom of this (5 days
work so far). Many thanks



>
>
> >
> >
> > thanks
> >
> > On Tue, Mar 28, 2017 at 9:39 PM, Martin Grigorov 
> > wrote:
> >
> > > Hi,
> > >
> > > Did you mention already which version of Wicket you use ?
> > > There was an improvement related to reusing the page parameters when
> > > constructing a new page instance in 7.0.0.
> > > I have the feeling you are using 6.x. Am I correct ?
> > >
> > > Martin Grigorov
> > > Wicket Training and Consulting
> > > https://twitter.com/mtgrigorov
> > >
> > > On Tue, Mar 28, 2017 at 7:22 PM, Wayne W 
> > > wrote:
> > >
> > > > Hello Martin,
> > > >
> > > > so I've been trying to still get to the bottom of this days later. So
> > my
> > > > understanding is getting better and it appears that the session
> itself
> > is
> > > > replicated fine. However I've tracked my issue down to the following:
> > > >
> > > > - If I have a page that has 2 links at the top. Link A is a
> > Bookmarkable
> > > > link back to the same page - it is also mounted thus:  mountPage(
> > > > "/cube/documents/${0}", CubeDocumentPage.class); It has a Long page
> > param
> > > > needed to construct the page ( i.e. /cube/documents/12345 ). The
> second
> > > > link B is just a simple new Link("B")  .
> > > > - If both instances are up and running , lets say I am on instance
> A. I
> > > > visit link A 3 times. I then kill instance A and I am balanced over
> to
> > > > instance B. If I visit link B ,  the PageStoreManager cannot find the
> > > page
> > > > that contains link B in the store and then tries to create a new
> > instance
> > > > of the page - the problem is then for some reason the page parameters
> > are
> > > > always null and the Long is never passed. Why is the page parameter
> > > always
> > > > null here? Trying to debug it, is seems the IPageManager is got from
> > the
> > > > wicket Application instance and not the Session, and this
> IPageManager
> > > > looks for a RequestAdaptor. Somewhere the page parameters are lost?.
> > > >
> > > > However I can get it to work this way:
> > > > - start instance A, visit the page and say click link A 3 times.
> > > > - Now start up instance B
> > > > - Kill instance A
> > > > - Click on the link B and this time the PageStoreManager finds the
> page
> > > and
> > > > there the link B and everything works fine.
> > > > It only works if I don't visit another page just after instance B
> > starts
> > > > up.
> > > >
> > > >
> > > > I will do some more debugging tomorrow to try and 

Re: ComponentNotFoundException and Clustering failover

2017-03-30 Thread Martin Grigorov
On Thu, Mar 30, 2017 at 5:00 PM, Wayne W 
wrote:

> Hi Martin,
>
> yes we are on 6. I've just spent the day upgrading to 7 and got it running
> ok. I've been debugging and I'm confused to one aspect:
>
> The PageManager is stored in the Application. The page manger has the
> RequestAdaptor/PageStoreManager stored within that holds the pages and
> components. I observe that when a new instance joins the cluster this
> pagestoremanager SessionEntry is serialized across to the new instance.
> However further requests do NOT serialise the session entry across.
> If the original node is then shutdown, on the new instance the page (from
> the further requests) cannot be found in the pagestoremanager (its
> bookmarkable page) and a new instance must be constructed instead. This is
> where I get the problem as it can't find the component on the new instance
> (I'm still debugging why this is the case).
>
> However my question is whats the point of serialising across the
> SessionEntry if its not done on each session commit? Its only of use if the
> node is stop straight after the new instance is started.
>

Whenever a stateful pages is used (touched) the SessionEntry is updated,
i.e. the page is put into it.
The SessionEntry is stored as an attribute in the HTTP Session.
The web container has logic to detect if the HTTP session has been updated
in a request and if it was then it replicates the whole session to the
other nodes.
Once the session is replicated it is deserialized. Here
SessionEntry#readObject() comes to play. It reads the pages from the
SessionEntry and stores them into the disk (via IDiskStore).
So the stateful pages should be available in the disks of all nodes.
Stateless pages are always recreated from scratch, so they are not
replicated.


>
>
> thanks
>
> On Tue, Mar 28, 2017 at 9:39 PM, Martin Grigorov 
> wrote:
>
> > Hi,
> >
> > Did you mention already which version of Wicket you use ?
> > There was an improvement related to reusing the page parameters when
> > constructing a new page instance in 7.0.0.
> > I have the feeling you are using 6.x. Am I correct ?
> >
> > Martin Grigorov
> > Wicket Training and Consulting
> > https://twitter.com/mtgrigorov
> >
> > On Tue, Mar 28, 2017 at 7:22 PM, Wayne W 
> > wrote:
> >
> > > Hello Martin,
> > >
> > > so I've been trying to still get to the bottom of this days later. So
> my
> > > understanding is getting better and it appears that the session itself
> is
> > > replicated fine. However I've tracked my issue down to the following:
> > >
> > > - If I have a page that has 2 links at the top. Link A is a
> Bookmarkable
> > > link back to the same page - it is also mounted thus:  mountPage(
> > > "/cube/documents/${0}", CubeDocumentPage.class); It has a Long page
> param
> > > needed to construct the page ( i.e. /cube/documents/12345 ). The second
> > > link B is just a simple new Link("B")  .
> > > - If both instances are up and running , lets say I am on instance A. I
> > > visit link A 3 times. I then kill instance A and I am balanced over to
> > > instance B. If I visit link B ,  the PageStoreManager cannot find the
> > page
> > > that contains link B in the store and then tries to create a new
> instance
> > > of the page - the problem is then for some reason the page parameters
> are
> > > always null and the Long is never passed. Why is the page parameter
> > always
> > > null here? Trying to debug it, is seems the IPageManager is got from
> the
> > > wicket Application instance and not the Session, and this IPageManager
> > > looks for a RequestAdaptor. Somewhere the page parameters are lost?.
> > >
> > > However I can get it to work this way:
> > > - start instance A, visit the page and say click link A 3 times.
> > > - Now start up instance B
> > > - Kill instance A
> > > - Click on the link B and this time the PageStoreManager finds the page
> > and
> > > there the link B and everything works fine.
> > > It only works if I don't visit another page just after instance B
> starts
> > > up.
> > >
> > >
> > > I will do some more debugging tomorrow to try and understand this
> > > PageStoreManager/request adaptor bit more. But if you have any ideas
> I'd
> > > appreciate it.
> > > Thanks
> > >
> > >
> > >
> > > On Fri, Mar 24, 2017 at 12:48 PM, Martin Grigorov <
> mgrigo...@apache.org>
> > > wrote:
> > >
> > > > Hi,
> > > >
> > > > On Fri, Mar 24, 2017 at 1:31 PM, Wayne W <
> waynemailingli...@gmail.com>
> > > > wrote:
> > > >
> > > > > Thanks Martin,
> > > > >
> > > > > I have a theory what this is, perhaps you could confirm?
> > > > >
> > > > > What I observe is the following with the replication: If I visit
> > page A
> > > > and
> > > > > then visit page B, then kill the instance I am on the session is
> > > > > successfully failed over to the other node. Now I'm still looking
> at
> > > > page B
> > > > > in the browser - if I hit back on the browser I get
> > > 

Re: ComponentNotFoundException and Clustering failover

2017-03-30 Thread Wayne W
Hi Martin,

yes we are on 6. I've just spent the day upgrading to 7 and got it running
ok. I've been debugging and I'm confused to one aspect:

The PageManager is stored in the Application. The page manger has the
RequestAdaptor/PageStoreManager stored within that holds the pages and
components. I observe that when a new instance joins the cluster this
pagestoremanager SessionEntry is serialized across to the new instance.
However further requests do NOT serialise the session entry across.
If the original node is then shutdown, on the new instance the page (from
the further requests) cannot be found in the pagestoremanager (its
bookmarkable page) and a new instance must be constructed instead. This is
where I get the problem as it can't find the component on the new instance
(I'm still debugging why this is the case).

However my question is whats the point of serialising across the
SessionEntry if its not done on each session commit? Its only of use if the
node is stop straight after the new instance is started.


thanks

On Tue, Mar 28, 2017 at 9:39 PM, Martin Grigorov 
wrote:

> Hi,
>
> Did you mention already which version of Wicket you use ?
> There was an improvement related to reusing the page parameters when
> constructing a new page instance in 7.0.0.
> I have the feeling you are using 6.x. Am I correct ?
>
> Martin Grigorov
> Wicket Training and Consulting
> https://twitter.com/mtgrigorov
>
> On Tue, Mar 28, 2017 at 7:22 PM, Wayne W 
> wrote:
>
> > Hello Martin,
> >
> > so I've been trying to still get to the bottom of this days later. So my
> > understanding is getting better and it appears that the session itself is
> > replicated fine. However I've tracked my issue down to the following:
> >
> > - If I have a page that has 2 links at the top. Link A is a Bookmarkable
> > link back to the same page - it is also mounted thus:  mountPage(
> > "/cube/documents/${0}", CubeDocumentPage.class); It has a Long page param
> > needed to construct the page ( i.e. /cube/documents/12345 ). The second
> > link B is just a simple new Link("B")  .
> > - If both instances are up and running , lets say I am on instance A. I
> > visit link A 3 times. I then kill instance A and I am balanced over to
> > instance B. If I visit link B ,  the PageStoreManager cannot find the
> page
> > that contains link B in the store and then tries to create a new instance
> > of the page - the problem is then for some reason the page parameters are
> > always null and the Long is never passed. Why is the page parameter
> always
> > null here? Trying to debug it, is seems the IPageManager is got from the
> > wicket Application instance and not the Session, and this IPageManager
> > looks for a RequestAdaptor. Somewhere the page parameters are lost?.
> >
> > However I can get it to work this way:
> > - start instance A, visit the page and say click link A 3 times.
> > - Now start up instance B
> > - Kill instance A
> > - Click on the link B and this time the PageStoreManager finds the page
> and
> > there the link B and everything works fine.
> > It only works if I don't visit another page just after instance B starts
> > up.
> >
> >
> > I will do some more debugging tomorrow to try and understand this
> > PageStoreManager/request adaptor bit more. But if you have any ideas I'd
> > appreciate it.
> > Thanks
> >
> >
> >
> > On Fri, Mar 24, 2017 at 12:48 PM, Martin Grigorov 
> > wrote:
> >
> > > Hi,
> > >
> > > On Fri, Mar 24, 2017 at 1:31 PM, Wayne W 
> > > wrote:
> > >
> > > > Thanks Martin,
> > > >
> > > > I have a theory what this is, perhaps you could confirm?
> > > >
> > > > What I observe is the following with the replication: If I visit
> page A
> > > and
> > > > then visit page B, then kill the instance I am on the session is
> > > > successfully failed over to the other node. Now I'm still looking at
> > > page B
> > > > in the browser - if I hit back on the browser I get
> > PageExpiredException.
> > > > Is this the expected behaviour?
> > > >
> > >
> > > No.
> > > The expected behavior is to see the latest state of page A.
> > >
> > >
> > > >
> > > > If it IS the expected behaviour, then the reason I think that I have
> an
> > > > issue with the page with the AbstractDefaultAjaxBehavior is because
> the
> > > > code in the AbstractDefaultAjaxBehaviour.respond is adding
> components
> > to
> > > > the page which in turn marks the Session dirty which in turn
> replicates
> > > the
> > > > session. If only the last page/session commit is only replicated it
> > could
> > > > explain why I get a ComponentNotFound exception from the page as
> > > > it overwriten by the update from the AbstractDefaultAjaxBehavior
> > > >
> > >
> > > Any time the page is marked as dirty Wicket will store it in 1) the
> HTTP
> > > session and 2) on the disk
> > > 1) will notify the web server (e.g. Tomcat) that it has to replicate
> the
> > > 

Re: Quick Start Wicket version

2017-03-30 Thread Maxim Solodovnik
sure:

Steps:
1) go to create quickstart page [1]
2) choose 8.0.0-SNAPSHOT
3) copy/create project [2]
4) cd myproject
5) mvn jetty:run
Result: Stack trace [3]

Workaround: remove all https/ssl related jetty components

*[1]* http://wicket.apache.org/start/quickstart.html
*[2]* mvn archetype:generate -DarchetypeGroupId=org.apache.wicket
-DarchetypeArtifactId=wicket-archetype-quickstart
-DarchetypeVersion=8.0.0-SNAPSHOT -DgroupId=com.mycompany
-DartifactId=myproject -DarchetypeRepository=
https://repository.apache.org/content/repositories/snapshots/
-DinteractiveMode=false
*[3] *
[ERROR] Failed to execute goal
org.eclipse.jetty:jetty-maven-plugin:9.4.3.v20170317:run (default-cli) on
project myproject: Failure: Invalid keystore format -> [Help 1]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e
switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions,
please read the following articles:
[ERROR] [Help 1]
http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException
Exception in thread "Thread-1" java.lang.NoClassDefFoundError:
org/eclipse/jetty/io/ManagedSelector$CloseEndPoints
at org.eclipse.jetty.io.ManagedSelector.doStop(ManagedSelector.java:135)
at
org.eclipse.jetty.util.component.AbstractLifeCycle.stop(AbstractLifeCycle.java:89)
at
org.eclipse.jetty.util.component.ContainerLifeCycle.stop(ContainerLifeCycle.java:142)
at
org.eclipse.jetty.util.component.ContainerLifeCycle.doStop(ContainerLifeCycle.java:160)
at org.eclipse.jetty.io.SelectorManager.doStop(SelectorManager.java:257)
at
org.eclipse.jetty.util.component.AbstractLifeCycle.stop(AbstractLifeCycle.java:89)
at
org.eclipse.jetty.util.component.ContainerLifeCycle.stop(ContainerLifeCycle.java:142)
at
org.eclipse.jetty.util.component.ContainerLifeCycle.doStop(ContainerLifeCycle.java:160)
at
org.eclipse.jetty.client.AbstractHttpClientTransport.doStop(AbstractHttpClientTransport.java:87)
at
org.eclipse.jetty.util.component.AbstractLifeCycle.stop(AbstractLifeCycle.java:89)
at
org.eclipse.jetty.util.component.ContainerLifeCycle.stop(ContainerLifeCycle.java:142)
at
org.eclipse.jetty.util.component.ContainerLifeCycle.doStop(ContainerLifeCycle.java:160)
at org.eclipse.jetty.client.HttpClient.doStop(HttpClient.java:254)
at
org.eclipse.jetty.util.component.AbstractLifeCycle.stop(AbstractLifeCycle.java:89)
at
org.eclipse.jetty.util.component.ContainerLifeCycle.stop(ContainerLifeCycle.java:142)
at
org.eclipse.jetty.util.component.ContainerLifeCycle.doStop(ContainerLifeCycle.java:160)
at
org.eclipse.jetty.websocket.client.WebSocketClient.doStop(WebSocketClient.java:376)
at
org.eclipse.jetty.util.component.AbstractLifeCycle.stop(AbstractLifeCycle.java:89)
at
org.eclipse.jetty.util.component.ContainerLifeCycle.stop(ContainerLifeCycle.java:142)
at
org.eclipse.jetty.util.component.ContainerLifeCycle.doStop(ContainerLifeCycle.java:160)
at
org.eclipse.jetty.websocket.jsr356.ClientContainer.doStop(ClientContainer.java:214)
at
org.eclipse.jetty.util.component.AbstractLifeCycle.stop(AbstractLifeCycle.java:89)
at org.eclipse.jetty.util.thread.ShutdownThread.run(ShutdownThread.java:138)
Caused by: java.lang.ClassNotFoundException:
org.eclipse.jetty.io.ManagedSelector$CloseEndPoints
at
org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy.loadClass(SelfFirstStrategy.java:50)
at
org.codehaus.plexus.classworlds.realm.ClassRealm.unsynchronizedLoadClass(ClassRealm.java:271)
at
org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:247)
at
org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:239)
... 23 more



On Thu, Mar 30, 2017 at 8:01 PM, Andrea Del Bene 
wrote:

> Hi Maxim,
>
> can you provide more details about the problem with jetty:run?
>
> thank you.
>
> On Thu, Mar 30, 2017 at 2:38 PM, Maxim Solodovnik 
> wrote:
>
> > Another report:
> >
> > Latest wicket version still M4
> > Project created using latest 8.0.0-SNAPSHOT is not runnable using
> jetty:run
> >
> > On Thu, Mar 30, 2017 at 7:31 PM, Andrea Del Bene 
> > wrote:
> > > It sounds like a subliminal message :-)
> > >
> > > On Thu, Mar 30, 2017 at 11:13 AM, Martin Grigorov <
> mgrigo...@apache.org>
> > > wrote:
> > >
> > >> Hi,
> > >>
> > >> Thanks for the report!
> > >> I've fixed this few months ago:
> > >> https://github.com/apache/wicket/commit/
> 86f7cb04020c5298e3408aea56c94e
> > >> 744afed155
> > >> Maybe it is time for 7.7.0. 7.6.0 has been released 3 months ago!
> > >>
> > >> Martin Grigorov
> > >> Wicket Training and Consulting
> > >> https://twitter.com/mtgrigorov
> > >>
> > >> On Thu, Mar 30, 2017 at 10:49 AM, Peter Henderson <
> > >> peter.hender...@starjar.com> wrote:
> > >>
> > >> > Hi all.
> > >> >
> > >> > I've just created a quick start from [1] using [2]
> > >> >
> > >> > The resulting project (pom.xml) is using
> > >> > 7.5.0-SNAPSHOT
> > >> >
> > 

Re: Quick Start Wicket version

2017-03-30 Thread Andrea Del Bene
Hi Maxim,

can you provide more details about the problem with jetty:run?

thank you.

On Thu, Mar 30, 2017 at 2:38 PM, Maxim Solodovnik 
wrote:

> Another report:
>
> Latest wicket version still M4
> Project created using latest 8.0.0-SNAPSHOT is not runnable using jetty:run
>
> On Thu, Mar 30, 2017 at 7:31 PM, Andrea Del Bene 
> wrote:
> > It sounds like a subliminal message :-)
> >
> > On Thu, Mar 30, 2017 at 11:13 AM, Martin Grigorov 
> > wrote:
> >
> >> Hi,
> >>
> >> Thanks for the report!
> >> I've fixed this few months ago:
> >> https://github.com/apache/wicket/commit/86f7cb04020c5298e3408aea56c94e
> >> 744afed155
> >> Maybe it is time for 7.7.0. 7.6.0 has been released 3 months ago!
> >>
> >> Martin Grigorov
> >> Wicket Training and Consulting
> >> https://twitter.com/mtgrigorov
> >>
> >> On Thu, Mar 30, 2017 at 10:49 AM, Peter Henderson <
> >> peter.hender...@starjar.com> wrote:
> >>
> >> > Hi all.
> >> >
> >> > I've just created a quick start from [1] using [2]
> >> >
> >> > The resulting project (pom.xml) is using
> >> > 7.5.0-SNAPSHOT
> >> >
> >> > Probably something trivial to fix in the project template?
> >> >
> >> > Peter.
> >> >
> >> >
> >> >
> >> >
> >> > [1]
> >> > http://wicket.apache.org/start/quickstart.html
> >> >
> >> > [2]
> >> > mvn archetype:generate -DarchetypeGroupId=org.apache.wicket
> >> > -DarchetypeArtifactId=wicket-archetype-quickstart
> >> -DarchetypeVersion=7.6.0
> >> > -DgroupId=com.mycompany -DartifactId=redirect -DarchetypeRepository=
> >> > https://repository.apache.org/ -DinteractiveMode=false
> >> >
> >> >
> >> >
> >> >
> >> > --
> >> > Peter Henderson
> >> >
> >>
>
>
>
> --
> WBR
> Maxim aka solomax
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>


Re: Quick Start Wicket version

2017-03-30 Thread Maxim Solodovnik
Another report:

Latest wicket version still M4
Project created using latest 8.0.0-SNAPSHOT is not runnable using jetty:run

On Thu, Mar 30, 2017 at 7:31 PM, Andrea Del Bene  wrote:
> It sounds like a subliminal message :-)
>
> On Thu, Mar 30, 2017 at 11:13 AM, Martin Grigorov 
> wrote:
>
>> Hi,
>>
>> Thanks for the report!
>> I've fixed this few months ago:
>> https://github.com/apache/wicket/commit/86f7cb04020c5298e3408aea56c94e
>> 744afed155
>> Maybe it is time for 7.7.0. 7.6.0 has been released 3 months ago!
>>
>> Martin Grigorov
>> Wicket Training and Consulting
>> https://twitter.com/mtgrigorov
>>
>> On Thu, Mar 30, 2017 at 10:49 AM, Peter Henderson <
>> peter.hender...@starjar.com> wrote:
>>
>> > Hi all.
>> >
>> > I've just created a quick start from [1] using [2]
>> >
>> > The resulting project (pom.xml) is using
>> > 7.5.0-SNAPSHOT
>> >
>> > Probably something trivial to fix in the project template?
>> >
>> > Peter.
>> >
>> >
>> >
>> >
>> > [1]
>> > http://wicket.apache.org/start/quickstart.html
>> >
>> > [2]
>> > mvn archetype:generate -DarchetypeGroupId=org.apache.wicket
>> > -DarchetypeArtifactId=wicket-archetype-quickstart
>> -DarchetypeVersion=7.6.0
>> > -DgroupId=com.mycompany -DartifactId=redirect -DarchetypeRepository=
>> > https://repository.apache.org/ -DinteractiveMode=false
>> >
>> >
>> >
>> >
>> > --
>> > Peter Henderson
>> >
>>



-- 
WBR
Maxim aka solomax

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



Re: Quick Start Wicket version

2017-03-30 Thread Andrea Del Bene
It sounds like a subliminal message :-)

On Thu, Mar 30, 2017 at 11:13 AM, Martin Grigorov 
wrote:

> Hi,
>
> Thanks for the report!
> I've fixed this few months ago:
> https://github.com/apache/wicket/commit/86f7cb04020c5298e3408aea56c94e
> 744afed155
> Maybe it is time for 7.7.0. 7.6.0 has been released 3 months ago!
>
> Martin Grigorov
> Wicket Training and Consulting
> https://twitter.com/mtgrigorov
>
> On Thu, Mar 30, 2017 at 10:49 AM, Peter Henderson <
> peter.hender...@starjar.com> wrote:
>
> > Hi all.
> >
> > I've just created a quick start from [1] using [2]
> >
> > The resulting project (pom.xml) is using
> > 7.5.0-SNAPSHOT
> >
> > Probably something trivial to fix in the project template?
> >
> > Peter.
> >
> >
> >
> >
> > [1]
> > http://wicket.apache.org/start/quickstart.html
> >
> > [2]
> > mvn archetype:generate -DarchetypeGroupId=org.apache.wicket
> > -DarchetypeArtifactId=wicket-archetype-quickstart
> -DarchetypeVersion=7.6.0
> > -DgroupId=com.mycompany -DartifactId=redirect -DarchetypeRepository=
> > https://repository.apache.org/ -DinteractiveMode=false
> >
> >
> >
> >
> > --
> > Peter Henderson
> >
>


Why AjaxLink start only after I refresh side?

2017-03-30 Thread Sokab
Hi Everyone. I followed this tutorial (
https://www.youtube.com/watch?v=gdXZDsaA1K0=PLon8X6Hq3cnI8bH-skje0NFegYXG97K3t=6
) I want display ModalWindow but first i need some reaction after click on
button but I don't see any reaction... it is possible only when I refresh
this page. What is wrong with that?

MoviesToWatch.html (This page is diplay inside Wicket Border ):



TODO supply a title






Add Movie



 view <#>  




//##
MoviesToWatch.java

public class MoviesToWatch extends WebPage{

private ModalWindow modalWindow;

public MoviesToWatch() {

UserContentBorder userContentBorder = new
UserContentBorder("moviesToWatch"); // Border

//* Part with ModalWindow  *
modalWindow = new ModalWindow("modalWindow");

modalWindow.setPageCreator(new PageCreator(){
@Override
public Page createPage() {
return new ModalAddMovies();   //simple web page
}

});

modalWindow.setWindowClosedCallback(new WindowClosedCallback(){
@Override
public void onClose(AjaxRequestTarget art) {
//TODO
}

});

//* Part with AjaxLink  *


AjaxLink link1 = new AjaxLink("viewLink")
{
@Override
public void onClick(AjaxRequestTarget target) {// <-- this
method is not colled after click (it work after refresh side)
System.out.println("I AM INSIDE");
//modalWindow.show(target);
}
};


userContentBorder.add(link1);
userContentBorder.add(modalWindow);
add(userContentBorder);
}
  
}
//##
UserContentBorder.hrml:



TODO supply a title









 Home <#>  









 My Movies <#>  
 Movies To Watch <#>  














//##
UserContentBorder.java:

public class UserContentBorder extends Border{

public UserContentBorder(String id) {
super(id);

MyBorderNavbarLeft myBorderNavbarLeft = new
MyBorderNavbarLeft("navigationLeft");
MyBorderNavbar myBorderNavbar = new MyBorderNavbar("navigation");

this.addToBorder(myBorderNavbar);
this.addToBorder(myBorderNavbarLeft);
this.addToBorder(new MyBorderBody("bodyBorder"));

Link homePage = new Link("homePage"){
@Override
public void onClick() {
this.setResponsePage(new HomePage());
}
};
myBorderNavbar.add(homePage);

Link myMovies = new Link("myMovies"){
@Override
public void onClick() {
this.setResponsePage(new MyMovies());
}
};
myBorderNavbarLeft.add(myMovies);

Link moviesToWatch = new Link("moviesToWatch"){
@Override
public void onClick() {
this.setResponsePage(new MoviesToWatch());
}
};
myBorderNavbarLeft.add(moviesToWatch);
}

}

--
View this message in context: 
http://apache-wicket.1842946.n4.nabble.com/Why-AjaxLink-start-only-after-I-refresh-side-tp4677524.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: Quick Start Wicket version

2017-03-30 Thread Martin Grigorov
Hi,

Thanks for the report!
I've fixed this few months ago:
https://github.com/apache/wicket/commit/86f7cb04020c5298e3408aea56c94e744afed155
Maybe it is time for 7.7.0. 7.6.0 has been released 3 months ago!

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

On Thu, Mar 30, 2017 at 10:49 AM, Peter Henderson <
peter.hender...@starjar.com> wrote:

> Hi all.
>
> I've just created a quick start from [1] using [2]
>
> The resulting project (pom.xml) is using
> 7.5.0-SNAPSHOT
>
> Probably something trivial to fix in the project template?
>
> Peter.
>
>
>
>
> [1]
> http://wicket.apache.org/start/quickstart.html
>
> [2]
> mvn archetype:generate -DarchetypeGroupId=org.apache.wicket
> -DarchetypeArtifactId=wicket-archetype-quickstart -DarchetypeVersion=7.6.0
> -DgroupId=com.mycompany -DartifactId=redirect -DarchetypeRepository=
> https://repository.apache.org/ -DinteractiveMode=false
>
>
>
>
> --
> Peter Henderson
>


Quick Start Wicket version

2017-03-30 Thread Peter Henderson
Hi all.

I've just created a quick start from [1] using [2]

The resulting project (pom.xml) is using
7.5.0-SNAPSHOT

Probably something trivial to fix in the project template?

Peter.




[1]
http://wicket.apache.org/start/quickstart.html

[2]
mvn archetype:generate -DarchetypeGroupId=org.apache.wicket
-DarchetypeArtifactId=wicket-archetype-quickstart -DarchetypeVersion=7.6.0
-DgroupId=com.mycompany -DartifactId=redirect -DarchetypeRepository=
https://repository.apache.org/ -DinteractiveMode=false




-- 
Peter Henderson