What is the cause for log entry ModificationWatcher - Cannot track modifications to resource

2012-01-02 Thread Per Newgro

Hi,

If i test my app by using Start.java i get the log entry
INFO  - ModificationWatcher- Cannot track modifications to 
resource 
file:/D:/Dokumente%20und%20Einstellungen/per.n/Eigene%20Dateien/workspaces/work/whataschranz/target/classes/ch/newgro/shop/whataschranz/welcome/HomePage.html

If i change the HP Markup it's not reloaded.

Google only pops up an answer by igor
not sure you can do anything about the message...just disable the 
logger for that class/package...


But disabling the log message is not solving the problem, that my markup 
modifications are not re-loaded :-).
As far as i investigated this issue is a problem with the encoded path 
string (%20) used to load the resource by
org.apache.wicket.util.resource.locator.ResourceStreamLocator#locateByResourceFinder. 

I'm not an expert but i think i've read a message that something changed 
here (URI class or servlet-api)

but maybe someone else already solved this.

My question is - Is this a bug or can i configure something to make 
resource modification watcher working?


Thanks
Per

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



Re: What is the cause for log entry ModificationWatcher - Cannot track modifications to resource

2012-01-02 Thread Allen Gilbert
Per,

I ran into this problem recently and solved it by removing spaces from
directory names in my project path.  I plan to file a Jira issue at some
point, as it seems that ModificationWatcher should be able to handle file
paths with spaces...

-Allen

On Mon, Jan 2, 2012 at 4:42 AM, Per Newgro per.new...@gmx.ch wrote:

 Hi,

 If i test my app by using Start.java i get the log entry
 INFO  - ModificationWatcher- Cannot track modifications to
 resource file:/D:/Dokumente%20und%**20Einstellungen/per.n/Eigene%**
 20Dateien/workspaces/work/**whataschranz/target/classes/**
 ch/newgro/shop/whataschranz/**welcome/HomePage.html
 If i change the HP Markup it's not reloaded.

 Google only pops up an answer by igor
 not sure you can do anything about the message...just disable the logger
 for that class/package...

 But disabling the log message is not solving the problem, that my markup
 modifications are not re-loaded :-).
 As far as i investigated this issue is a problem with the encoded path
 string (%20) used to load the resource by
 org.apache.wicket.util.**resource.locator.**ResourceStreamLocator#**locateByResourceFinder.

 I'm not an expert but i think i've read a message that something changed
 here (URI class or servlet-api)
 but maybe someone else already solved this.

 My question is - Is this a bug or can i configure something to make
 resource modification watcher working?

 Thanks
 Per

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




RE: Can't build wicket from updated trunk

2012-01-02 Thread Chris Colman
Dumping the environment variables shows only these maven related variables are 
set:

M2
M2_HOME

I can't see any other places where MAVEN_OPTS is being set. Nothing in maven's 
settings.xml that refers to any JVM heap size options.

I noticed my version of maven is 2.2.1 dated 2009-08-07 so maybe I should 
update to the latest maven release and see if it establishes a larger default 
JVM heap size.

-Original Message-
From: Martin Grigorov [mailto:mgrigo...@apache.org]
Sent: Monday, 2 January 2012 6:44 PM
To: users@wicket.apache.org
Subject: Re: Can't build wicket from updated trunk

I don't set any JVM settings to be able to build Wicket...

@Chris: do you have some globally exported MAVEN_OPTS which may interfere ?

On Mon, Jan 2, 2012 at 6:52 AM, Matthias Gasser
matthias.gas...@gmail.com wrote:
 You need to increase the heap space for maven.

 Just run the following line prior building:

  snip 
 set MAVEN_OPTS=-Xmx1024m -XX:MaxPermSize=128m
  snap 

 That should bring you through.

 -matthias

 Am 02.01.2012 um 05:43 schrieb Chris Colman:

 I cloned the wicket git repos and then checked out branch wicket-1.5.x
branch and the build broke in a different place (it got a bit further this
time :)  )

 The build was done on a Windows XP box with 4GB RAM so I wouldn't have
thought it would have run out of memory.

 [INFO] 1 error
 [INFO] -
 [INFO] -
---
 [ERROR] BUILD FAILURE
 [INFO] -
---
 [INFO] Compilation failure
 Failure executing javac, but could not parse the error:


 The system is out of resources.
 Consult the following stack trace for details.
 java.lang.OutOfMemoryError: Java heap space
        at
com.sun.tools.javac.code.Scope$ImportScope.makeEntry(Scope.java:385)
        at com.sun.tools.javac.code.Scope.enter(Scope.java:196)
        at com.sun.tools.javac.code.Scope.enter(Scope.java:183)
        at
com.sun.tools.javac.comp.MemberEnter.importAll(MemberEnter.java:132)
        at
com.sun.tools.javac.comp.MemberEnter.visitTopLevel(MemberEnter.java:509)
        at
com.sun.tools.javac.tree.JCTree$JCCompilationUnit.accept(JCTree.java:446)
        at
com.sun.tools.javac.comp.MemberEnter.memberEnter(MemberEnter.java:387)
        at
com.sun.tools.javac.comp.MemberEnter.complete(MemberEnter.java:819)
        at com.sun.tools.javac.code.Symbol.complete(Symbol.java:386)
        at
com.sun.tools.javac.code.Symbol$ClassSymbol.complete(Symbol.java:758)
        at com.sun.tools.javac.comp.Enter.complete(Enter.java:451)
        at com.sun.tools.javac.comp.Enter.main(Enter.java:429)
        at
com.sun.tools.javac.main.JavaCompiler.enterTrees(JavaCompiler.java:819)
        at
com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:727)
        at com.sun.tools.javac.main.Main.compile(Main.java:353)
        at com.sun.tools.javac.main.Main.compile(Main.java:279)
        at com.sun.tools.javac.main.Main.compile(Main.java:270)
        at com.sun.tools.javac.Main.compile(Main.java:87)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:3
9)
        at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImp
l.java:25)
        at java.lang.reflect.Method.invoke(Method.java:597)
        at
org.codehaus.plexus.compiler.javac.JavacCompiler.compileInProcess(JavacComp
iler.java:554)
        at
org.codehaus.plexus.compiler.javac.JavacCompiler.compile(JavacCompiler.java
:161)
        at
org.apache.maven.plugin.AbstractCompilerMojo.execute(AbstractCompilerMojo.j
ava:605)
        at
org.apache.maven.plugin.CompilerMojo.execute(CompilerMojo.java:128)
        at
org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManag
er.java:490)
        at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLif
ecycleExecutor.java:694)
        at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycl
e(DefaultLifecycleExecutor.java:556)
        at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLife
cycleExecutor.java:535)
        at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFai
lures(DefaultLifecycleExecutor.java:387)
        at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(Def
aultLifecycleExecutor.java:348)

 -Original Message-
 From: Igor Vaynberg [mailto:igor.vaynb...@gmail.com]
 Sent: Monday, 2 January 2012 2:50 PM
 To: users@wicket.apache.org
 Subject: Re: Can't build wicket from updated trunk

 already moved.

 -igor

 On Sun, Jan 1, 2012 at 7:31 PM, Chris Colman
 chr...@stepaheadsoftware.com wrote:
 Is Wicket moving to git?

 Chris

 -Original Message-
 From: Igor Vaynberg [mailto:igor.vaynb...@gmail.com]
 Sent: Monday, 2 January 2012 

RE: Can't build wicket from updated trunk

2012-01-02 Thread Chris Colman
Well it certainly works a lot better with Maven 3.0.3! ;)

It still can't build core because of some test failures:

Running org.apache.wicket.protocol.http.StoredResponsesMapTest
Tests run: 4, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 19.351 sec  
FAILURE!
Running org.apache.wicket.VisitorTest
Tests run: 6, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0 sec
Running org.apache.wicket.ajax.AjaxBehaviorAndMetaDataTest
Tests run: 1, Failures: 0, Errors: 0, Skipped: 1, Time elapsed: 0 sec
Running org.apache.wicket.page.PageAccessSynchronizerTest
Tests run: 6, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 22.488 sec  
FAILURE!

Results :

Failed tests:   
getExpiredValue(org.apache.wicket.protocol.http.StoredResponsesMapTest)
  testBlocking(org.apache.wicket.page.PageAccessSynchronizerTest)

Tests run: 1264, Failures: 2, Errors: 0, Skipped: 2


-Original Message-
From: Martin Grigorov [mailto:mgrigo...@apache.org]
Sent: Monday, 2 January 2012 6:44 PM
To: users@wicket.apache.org
Subject: Re: Can't build wicket from updated trunk

I don't set any JVM settings to be able to build Wicket...

@Chris: do you have some globally exported MAVEN_OPTS which may interfere ?

On Mon, Jan 2, 2012 at 6:52 AM, Matthias Gasser
matthias.gas...@gmail.com wrote:
 You need to increase the heap space for maven.

 Just run the following line prior building:

  snip 
 set MAVEN_OPTS=-Xmx1024m -XX:MaxPermSize=128m
  snap 

 That should bring you through.

 -matthias

 Am 02.01.2012 um 05:43 schrieb Chris Colman:

 I cloned the wicket git repos and then checked out branch wicket-1.5.x
branch and the build broke in a different place (it got a bit further this
time :)  )

 The build was done on a Windows XP box with 4GB RAM so I wouldn't have
thought it would have run out of memory.

 [INFO] 1 error
 [INFO] -
 [INFO] -
---
 [ERROR] BUILD FAILURE
 [INFO] -
---
 [INFO] Compilation failure
 Failure executing javac, but could not parse the error:


 The system is out of resources.
 Consult the following stack trace for details.
 java.lang.OutOfMemoryError: Java heap space
        at
com.sun.tools.javac.code.Scope$ImportScope.makeEntry(Scope.java:385)
        at com.sun.tools.javac.code.Scope.enter(Scope.java:196)
        at com.sun.tools.javac.code.Scope.enter(Scope.java:183)
        at
com.sun.tools.javac.comp.MemberEnter.importAll(MemberEnter.java:132)
        at
com.sun.tools.javac.comp.MemberEnter.visitTopLevel(MemberEnter.java:509)
        at
com.sun.tools.javac.tree.JCTree$JCCompilationUnit.accept(JCTree.java:446)
        at
com.sun.tools.javac.comp.MemberEnter.memberEnter(MemberEnter.java:387)
        at
com.sun.tools.javac.comp.MemberEnter.complete(MemberEnter.java:819)
        at com.sun.tools.javac.code.Symbol.complete(Symbol.java:386)
        at
com.sun.tools.javac.code.Symbol$ClassSymbol.complete(Symbol.java:758)
        at com.sun.tools.javac.comp.Enter.complete(Enter.java:451)
        at com.sun.tools.javac.comp.Enter.main(Enter.java:429)
        at
com.sun.tools.javac.main.JavaCompiler.enterTrees(JavaCompiler.java:819)
        at
com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:727)
        at com.sun.tools.javac.main.Main.compile(Main.java:353)
        at com.sun.tools.javac.main.Main.compile(Main.java:279)
        at com.sun.tools.javac.main.Main.compile(Main.java:270)
        at com.sun.tools.javac.Main.compile(Main.java:87)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:3
9)
        at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImp
l.java:25)
        at java.lang.reflect.Method.invoke(Method.java:597)
        at
org.codehaus.plexus.compiler.javac.JavacCompiler.compileInProcess(JavacComp
iler.java:554)
        at
org.codehaus.plexus.compiler.javac.JavacCompiler.compile(JavacCompiler.java
:161)
        at
org.apache.maven.plugin.AbstractCompilerMojo.execute(AbstractCompilerMojo.j
ava:605)
        at
org.apache.maven.plugin.CompilerMojo.execute(CompilerMojo.java:128)
        at
org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManag
er.java:490)
        at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLif
ecycleExecutor.java:694)
        at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycl
e(DefaultLifecycleExecutor.java:556)
        at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLife
cycleExecutor.java:535)
        at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFai
lures(DefaultLifecycleExecutor.java:387)
        at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(Def

Re: What is the cause for log entry ModificationWatcher - Cannot track modifications to resource

2012-01-02 Thread Per Newgro

Thanks Allen,

that's why i was asking in list first. So if you agree i will file a 
jira issue.


Per

Am 02.01.2012 18:14, schrieb Allen Gilbert:

Per,

I ran into this problem recently and solved it by removing spaces from
directory names in my project path.  I plan to file a Jira issue at some
point, as it seems that ModificationWatcher should be able to handle file
paths with spaces...

-Allen

On Mon, Jan 2, 2012 at 4:42 AM, Per Newgroper.new...@gmx.ch  wrote:


Hi,

If i test my app by using Start.java i get the log entry
INFO  - ModificationWatcher- Cannot track modifications to
resource file:/D:/Dokumente%20und%**20Einstellungen/per.n/Eigene%**
20Dateien/workspaces/work/**whataschranz/target/classes/**
ch/newgro/shop/whataschranz/**welcome/HomePage.html
If i change the HP Markup it's not reloaded.

Google only pops up an answer by igor
not sure you can do anything about the message...just disable the logger
for that class/package...

But disabling the log message is not solving the problem, that my markup
modifications are not re-loaded :-).
As far as i investigated this issue is a problem with the encoded path
string (%20) used to load the resource by
org.apache.wicket.util.**resource.locator.**ResourceStreamLocator#**locateByResourceFinder.

I'm not an expert but i think i've read a message that something changed
here (URI class or servlet-api)
but maybe someone else already solved this.

My question is - Is this a bug or can i configure something to make
resource modification watcher working?

Thanks
Per

--**--**-
To unsubscribe, e-mail: 
users-unsubscribe@wicket.**apache.orgusers-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: ModalWindow does not close cleanly

2012-01-02 Thread Nelson Segura
Any hope this can be fixed for 1.5.4? I will hate having to change all
our modals to have a dummy call back to get it to work :(
-Nelson

On Wed, Dec 21, 2011 at 2:59 PM, Nelson Segura nsegu...@gmail.com wrote:
 I have created a ticket, and attached a quick start to it

 https://issues.apache.org/jira/browse/WICKET-4311

 Notice that if you uncomment the dummy callback code, you will be able
 to reopen the modal.

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



Re: Can't open modal popups in ie8 or under

2012-01-02 Thread Nelson Segura
I applied the patch to my local version of 1.5.3, and it seems to
solve this issue.

On Fri, Dec 30, 2011 at 12:09 AM, northar josef.anders...@gmail.com wrote:
 Yes, tested with 1.5-snapshot now (not extensively), and it seems to work. My
 project manager will be glad


 --
 View this message in context: 
 http://apache-wicket.1842946.n4.nabble.com/Can-t-open-modal-popups-in-ie8-or-under-tp4241461p4245134.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


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



Re: Can't build wicket from updated trunk

2012-01-02 Thread Igor Vaynberg
skip the tests with -Dmaven.test.skip=true

-igor

On Mon, Jan 2, 2012 at 10:11 AM, Chris Colman
chr...@stepaheadsoftware.com wrote:
 Well it certainly works a lot better with Maven 3.0.3! ;)

 It still can't build core because of some test failures:

 Running org.apache.wicket.protocol.http.StoredResponsesMapTest
 Tests run: 4, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 19.351 sec 
  FAILURE!
 Running org.apache.wicket.VisitorTest
 Tests run: 6, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0 sec
 Running org.apache.wicket.ajax.AjaxBehaviorAndMetaDataTest
 Tests run: 1, Failures: 0, Errors: 0, Skipped: 1, Time elapsed: 0 sec
 Running org.apache.wicket.page.PageAccessSynchronizerTest
 Tests run: 6, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 22.488 sec 
  FAILURE!

 Results :

 Failed tests:   
 getExpiredValue(org.apache.wicket.protocol.http.StoredResponsesMapTest)
  testBlocking(org.apache.wicket.page.PageAccessSynchronizerTest)

 Tests run: 1264, Failures: 2, Errors: 0, Skipped: 2


-Original Message-
From: Martin Grigorov [mailto:mgrigo...@apache.org]
Sent: Monday, 2 January 2012 6:44 PM
To: users@wicket.apache.org
Subject: Re: Can't build wicket from updated trunk

I don't set any JVM settings to be able to build Wicket...

@Chris: do you have some globally exported MAVEN_OPTS which may interfere ?

On Mon, Jan 2, 2012 at 6:52 AM, Matthias Gasser
matthias.gas...@gmail.com wrote:
 You need to increase the heap space for maven.

 Just run the following line prior building:

  snip 
 set MAVEN_OPTS=-Xmx1024m -XX:MaxPermSize=128m
  snap 

 That should bring you through.

 -matthias

 Am 02.01.2012 um 05:43 schrieb Chris Colman:

 I cloned the wicket git repos and then checked out branch wicket-1.5.x
branch and the build broke in a different place (it got a bit further this
time :)  )

 The build was done on a Windows XP box with 4GB RAM so I wouldn't have
thought it would have run out of memory.

 [INFO] 1 error
 [INFO] -
 [INFO] -
---
 [ERROR] BUILD FAILURE
 [INFO] -
---
 [INFO] Compilation failure
 Failure executing javac, but could not parse the error:


 The system is out of resources.
 Consult the following stack trace for details.
 java.lang.OutOfMemoryError: Java heap space
        at
com.sun.tools.javac.code.Scope$ImportScope.makeEntry(Scope.java:385)
        at com.sun.tools.javac.code.Scope.enter(Scope.java:196)
        at com.sun.tools.javac.code.Scope.enter(Scope.java:183)
        at
com.sun.tools.javac.comp.MemberEnter.importAll(MemberEnter.java:132)
        at
com.sun.tools.javac.comp.MemberEnter.visitTopLevel(MemberEnter.java:509)
        at
com.sun.tools.javac.tree.JCTree$JCCompilationUnit.accept(JCTree.java:446)
        at
com.sun.tools.javac.comp.MemberEnter.memberEnter(MemberEnter.java:387)
        at
com.sun.tools.javac.comp.MemberEnter.complete(MemberEnter.java:819)
        at com.sun.tools.javac.code.Symbol.complete(Symbol.java:386)
        at
com.sun.tools.javac.code.Symbol$ClassSymbol.complete(Symbol.java:758)
        at com.sun.tools.javac.comp.Enter.complete(Enter.java:451)
        at com.sun.tools.javac.comp.Enter.main(Enter.java:429)
        at
com.sun.tools.javac.main.JavaCompiler.enterTrees(JavaCompiler.java:819)
        at
com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:727)
        at com.sun.tools.javac.main.Main.compile(Main.java:353)
        at com.sun.tools.javac.main.Main.compile(Main.java:279)
        at com.sun.tools.javac.main.Main.compile(Main.java:270)
        at com.sun.tools.javac.Main.compile(Main.java:87)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:3
9)
        at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImp
l.java:25)
        at java.lang.reflect.Method.invoke(Method.java:597)
        at
org.codehaus.plexus.compiler.javac.JavacCompiler.compileInProcess(JavacComp
iler.java:554)
        at
org.codehaus.plexus.compiler.javac.JavacCompiler.compile(JavacCompiler.java
:161)
        at
org.apache.maven.plugin.AbstractCompilerMojo.execute(AbstractCompilerMojo.j
ava:605)
        at
org.apache.maven.plugin.CompilerMojo.execute(CompilerMojo.java:128)
        at
org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManag
er.java:490)
        at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLif
ecycleExecutor.java:694)
        at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycl
e(DefaultLifecycleExecutor.java:556)
        at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLife
cycleExecutor.java:535)
        at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFai

Re: ModalWindow does not close cleanly

2012-01-02 Thread Igor Vaynberg
a patch is welcome :)

-igor

On Mon, Jan 2, 2012 at 10:24 AM, Nelson Segura nsegu...@gmail.com wrote:
 Any hope this can be fixed for 1.5.4? I will hate having to change all
 our modals to have a dummy call back to get it to work :(
 -Nelson

 On Wed, Dec 21, 2011 at 2:59 PM, Nelson Segura nsegu...@gmail.com wrote:
 I have created a ticket, and attached a quick start to it

 https://issues.apache.org/jira/browse/WICKET-4311

 Notice that if you uncomment the dummy callback code, you will be able
 to reopen the modal.

 -
 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: Hide page version query parameters

2012-01-02 Thread Taneli Korri
On Mon, Jan 2, 2012 at 9:47 AM, Martin Grigorov mgrigo...@apache.org wrote:
 On Mon, Jan 2, 2012 at 8:18 AM, Taneli Korri tko...@gmail.com wrote:
 On Sat, Dec 31, 2011 at 4:31 PM, Martin Grigorov mgrigo...@apache.org 
 wrote:
 On Sat, Dec 31, 2011 at 2:29 PM, Taneli Korri tko...@gmail.com wrote:
 On Sat, Dec 31, 2011 at 9:09 AM, Martin Grigorov mgrigo...@apache.org 
 wrote:
 On Fri, Dec 30, 2011 at 11:43 PM, martin.dilger
 martin.dil...@googlemail.com wrote:
 hi,
 you could try to change your render strategy to redirect to render, that
 would dismiss the page
 parameters version.

 This is not correct.
 The page id is encoded in the url only for stateful pages. Make your
 page stateless and it wont be there.


 OK, thanks for the info.

 If I remember correctly, in Wicket 1.4 stateful pages had also clean
 urls if the page was mounted to a certain path, i.e. the page version
 number was stored somewhere behind the scenes. I'm guessing this isn't
 possible anymore in Wicket 1.5?

 Everything is possible.
 The new IRequestMapper are easily extensible and you can even use your own 
 one.
 By default this special parameter is set so when the user presses F5
 (Refresh) the page Wicket will deliver the same version of the page.
 Otherwise a new instance will be created without the knowledge of the
 exact version.

 Why do you want to hide this parameter ?


 Plain and simple, I like clean urls that can be bookmarked.

 The urls with the page id can be bookmarked. If the requested version
 of the page is not available then a new version is created and
 delivered.


Ok, I think I can live with that. :)


 Also some of the search engine bots save the crawled urls (with
 parameters) and try to access them at a later time. I found this out
 when I updated one of my sites and now I'm seeing a lot of 500
 Internal error responses in my web server logs.

 Can you paste the stacktrace of an exception caused by such request ?


I should have been more clear, this case wasn't directly related to
the page version parameter, but to clean urls.

The thing is that I had a few stateful links in the frontpage which
changed the page stylesheet. Now when I have removed the links, I'm
seeing some crawlers still trying to request them.

For example, a get request to
/?0-1.ILinkListener-stylechooser-style1wicket:interface=:1:stylechooser:style2::ILinkListener::
throws this with Wicket 1.5.3:

ERROR org.apache.wicket.DefaultExceptionMapper  - Unexpected error occurred
org.apache.wicket.request.handler.ComponentNotFoundException: Could
not find component 'stylechooser:style1' on page 'class
net.korri.www.page.blog.BlogPage
at 
org.apache.wicket.request.handler.PageAndComponentProvider.getComponent(PageAndComponentProvider.java:167)
at 
org.apache.wicket.request.handler.ListenerInterfaceRequestHandler.getComponent(ListenerInterfaceRequestHandler.java:92)
at 
org.apache.wicket.request.handler.ListenerInterfaceRequestHandler.invokeListener(ListenerInterfaceRequestHandler.java:248)
at 
org.apache.wicket.request.handler.ListenerInterfaceRequestHandler.respond(ListenerInterfaceRequestHandler.java:234)
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)
at 
com.caucho.server.dispatch.FilterFilterChain.doFilter(FilterFilterChain.java:87)
at 
org.tuckey.web.filters.urlrewrite.RuleChain.handleRewrite(RuleChain.java:176)
at 
org.tuckey.web.filters.urlrewrite.RuleChain.doRules(RuleChain.java:145)
at 
org.tuckey.web.filters.urlrewrite.UrlRewriter.processRequest(UrlRewriter.java:92)
at 
org.tuckey.web.filters.urlrewrite.UrlRewriteFilter.doFilter(UrlRewriteFilter.java:381)
at 
com.caucho.server.dispatch.FilterFilterChain.doFilter(FilterFilterChain.java:87)
at 
com.caucho.server.webapp.WebAppFilterChain.doFilter(WebAppFilterChain.java:187)
at 
com.caucho.server.dispatch.ServletInvocation.service(ServletInvocation.java:265)
at 
com.caucho.server.http.HttpRequest.handleRequest(HttpRequest.java:273)
at com.caucho.server.port.TcpConnection.run(TcpConnection.java:682)
at com.caucho.util.ThreadPool$Item.runTasks(ThreadPool.java:743)
at com.caucho.util.ThreadPool$Item.run(ThreadPool.java:662)
at java.lang.Thread.run(Thread.java:662)

The request was valid earlier, but now since I've changed the site
there's no 

Infinite loop for user authentication when running on Apache2 as frontend server.

2012-01-02 Thread Niranjan Rao

Happy new year folks,

I have tomcat server running application war file serving only ajp 
protocol. Apache2 is configured to serve my application using ajp. This 
works - sometimes :( So far I have not able to figure out what breaks it 
or what makes it work and looking for help. The description of the 
problem is little complicated


Authentication on tomcat directly works expected. Authentication using 
apache2 as frontend server does work sometimes.


Whenever user tries to access the page that needs to be authenticated, 
it seems like wicket does not do redirect to login page, but serves the 
login page internally. Browser url does not change to login page. So if 
I try to access a page say mypage, wicket sends redirect /mypage - but 
next redirect actually serves the login page. I tried debugging tomcat 
instance and it seems like wicket does not get session cookie and 
creates a new session. So what firebug shows is number of redirects to 
the same url until firefox gets bored and shows up the error message. 
Things get especially interesting if remember me flag is checked. You 
are logged in to half of the page and other half (like ajax service 
calls) return the response that you need to login.


I have spent many hours trying to narrow the problem. On fresh browser 
with history cleaned up - specifically cookies, it all works very 
nicely. So apache2 does pass the cookies and wicket does see it. On the 
other hand if had logged in once and session expires (my theory, no 
proof), it does get into infinite redirect loop.


Any help/pointers are greatly appreciated.

Niranjan

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



signOut and port

2012-01-02 Thread brettTi
We're running a wicket app on jetty and having an issue with signout. The app
runs on port 8443 and we have iptables redirecting from port 443.  This lets
us go to https://ourap.lab without port numbers and without having the web
app run as root.

Everything is great until we do signout.  We have a LogoutPage that does
this:

   AuthenticatedWebSession.get().signOut();
   setResponsePage(HomePage.class);

Works fine, we get sent to the Login page.  Only problem is that the url has
the :8443 port number in it.  For some reason, this is the end of the world
for our users.

Any ideas?  Thanks





--
View this message in context: 
http://apache-wicket.1842946.n4.nabble.com/signOut-and-port-tp4254767p4254767.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: Hide page version query parameters

2012-01-02 Thread Igor Vaynberg
add the nofollow attribute to such links.

-igor

On Mon, Jan 2, 2012 at 11:05 AM, Taneli Korri tko...@gmail.com wrote:
 On Mon, Jan 2, 2012 at 9:47 AM, Martin Grigorov mgrigo...@apache.org wrote:
 On Mon, Jan 2, 2012 at 8:18 AM, Taneli Korri tko...@gmail.com wrote:
 On Sat, Dec 31, 2011 at 4:31 PM, Martin Grigorov mgrigo...@apache.org 
 wrote:
 On Sat, Dec 31, 2011 at 2:29 PM, Taneli Korri tko...@gmail.com wrote:
 On Sat, Dec 31, 2011 at 9:09 AM, Martin Grigorov mgrigo...@apache.org 
 wrote:
 On Fri, Dec 30, 2011 at 11:43 PM, martin.dilger
 martin.dil...@googlemail.com wrote:
 hi,
 you could try to change your render strategy to redirect to render, that
 would dismiss the page
 parameters version.

 This is not correct.
 The page id is encoded in the url only for stateful pages. Make your
 page stateless and it wont be there.


 OK, thanks for the info.

 If I remember correctly, in Wicket 1.4 stateful pages had also clean
 urls if the page was mounted to a certain path, i.e. the page version
 number was stored somewhere behind the scenes. I'm guessing this isn't
 possible anymore in Wicket 1.5?

 Everything is possible.
 The new IRequestMapper are easily extensible and you can even use your own 
 one.
 By default this special parameter is set so when the user presses F5
 (Refresh) the page Wicket will deliver the same version of the page.
 Otherwise a new instance will be created without the knowledge of the
 exact version.

 Why do you want to hide this parameter ?


 Plain and simple, I like clean urls that can be bookmarked.

 The urls with the page id can be bookmarked. If the requested version
 of the page is not available then a new version is created and
 delivered.


 Ok, I think I can live with that. :)


 Also some of the search engine bots save the crawled urls (with
 parameters) and try to access them at a later time. I found this out
 when I updated one of my sites and now I'm seeing a lot of 500
 Internal error responses in my web server logs.

 Can you paste the stacktrace of an exception caused by such request ?


 I should have been more clear, this case wasn't directly related to
 the page version parameter, but to clean urls.

 The thing is that I had a few stateful links in the frontpage which
 changed the page stylesheet. Now when I have removed the links, I'm
 seeing some crawlers still trying to request them.

 For example, a get request to
 /?0-1.ILinkListener-stylechooser-style1wicket:interface=:1:stylechooser:style2::ILinkListener::
 throws this with Wicket 1.5.3:

 ERROR org.apache.wicket.DefaultExceptionMapper  - Unexpected error occurred
 org.apache.wicket.request.handler.ComponentNotFoundException: Could
 not find component 'stylechooser:style1' on page 'class
 net.korri.www.page.blog.BlogPage
        at 
 org.apache.wicket.request.handler.PageAndComponentProvider.getComponent(PageAndComponentProvider.java:167)
        at 
 org.apache.wicket.request.handler.ListenerInterfaceRequestHandler.getComponent(ListenerInterfaceRequestHandler.java:92)
        at 
 org.apache.wicket.request.handler.ListenerInterfaceRequestHandler.invokeListener(ListenerInterfaceRequestHandler.java:248)
        at 
 org.apache.wicket.request.handler.ListenerInterfaceRequestHandler.respond(ListenerInterfaceRequestHandler.java:234)
        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)
        at 
 com.caucho.server.dispatch.FilterFilterChain.doFilter(FilterFilterChain.java:87)
        at 
 org.tuckey.web.filters.urlrewrite.RuleChain.handleRewrite(RuleChain.java:176)
        at 
 org.tuckey.web.filters.urlrewrite.RuleChain.doRules(RuleChain.java:145)
        at 
 org.tuckey.web.filters.urlrewrite.UrlRewriter.processRequest(UrlRewriter.java:92)
        at 
 org.tuckey.web.filters.urlrewrite.UrlRewriteFilter.doFilter(UrlRewriteFilter.java:381)
        at 
 com.caucho.server.dispatch.FilterFilterChain.doFilter(FilterFilterChain.java:87)
        at 
 com.caucho.server.webapp.WebAppFilterChain.doFilter(WebAppFilterChain.java:187)
        at 
 com.caucho.server.dispatch.ServletInvocation.service(ServletInvocation.java:265)
        at 
 com.caucho.server.http.HttpRequest.handleRequest(HttpRequest.java:273)
        at com.caucho.server.port.TcpConnection.run(TcpConnection.java:682)
        at com.caucho.util.ThreadPool$Item.runTasks(ThreadPool.java:743)
        at 

Re: ModalWindow does not close cleanly

2012-01-02 Thread Nelson Segura
:) A patch will be nice, but ... I think this has to do with my modal
window using page instead of panel. Could it be?

The window clears up the shown flag correctly if I press in the x
for the modal window, because the CloseButtonBehavior gets called, but
then the Ajax Target being used is in the context of the parent page.
The x icon sits outside the window.

My close/cancel button is calling window.close() directly, but that is
being executed inside the context of the modal page. The shown flag
is set up to false by window.close(), but it stays as true in the
context of the parent page. This prevents the page from being opened a
second time. Maybe something similar to how you cannot pass pages
directly to a modal, but instead should pass a page reference.
If I provide a dummy WindowClosedCallback, then the flag gets clear in
the context of the parent page.

I don't know if what I am saying is clear or correct, but I don't
exactly know where to start to fix this :(

-nelson

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



Re: ModalWindow does not close cleanly

2012-01-02 Thread Andrea Del Bene

On 01/03/2012 12:30 AM, Nelson Segura wrote:

  The shown flag is set up to false by window.close(), but it stays as true 
in the
context of the parent page. This prevents the page from being opened a
second time. Maybe something similar to how you cannot pass pages
directly to a modal, but instead should pass a page reference.
I agree with you. Your problem seems very similar to the one of passing 
page to modal.
I think this issue has to do with page serialization: when we try to 
open modal window a second time, Wicket uses the old versions of both 
main page and modal window where shown flag is true.



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



Re: ModalWindow does not close cleanly

2012-01-02 Thread Nelson Segura
I noticed also that if I add a dummy window closed call back to my page:

1) In the modal window, calling window.close() sets the shown flag to false
2) My dummy callback causes ModalWindow.WindowClosedBehavior to
respond. The current value of this shown flag is still true! Then the
behavior sets it to false again.

I believed that calling window.close() from inside a window that
uses page does not close the window cleanly.

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



RestartResponseAtInterceptPageException problem in 1.5

2012-01-02 Thread Zac Bedell
Greetings all,

I've run into some trouble using RestartResponseAtInterceptPageException since 
moving from Wicket 1.4.13 to 1.5.3.  The flow I'm implementing is a login via 
an OAuth service, so the user is redirected by way of RedirectPage to the OAuth 
provider and eventually ends up back at my site where 
continueToOriginalDestination() would send them back to the original page.  The 
problem is that RestartResponseAtInterceptPageException is capturing the URL to 
the Link object which triggers the login rather than the Page containing the 
link, and the URL the user is eventually redirected to is incorrect.  They end 
up with an AccessDeniedException rather than the originally requested page.

The Wicket object hierarchy looks like:

MyBasePage extends WebPage {
  public MyBasePage() {
add(new LoginLink(…));
  }
}

LoginLink {
  onClick() {
throw new RestartResponseAtInterceptPageException(new 
RedirectPage(getOAuthUrl()));
  }
}

// User clicks LoginLink on SomePage which extends MyBasePage, redirect to 
OAuth provider works correctly, ends up back at:
AuthCompletedPage extends WebPage {
  public AuthCompletedPage() {
markSessionLoggedIn(…);
continueToOriginalDestination();
  }
}


All of the redirect plumbing seems to work fine, but stepping through shows 
that the URL captured in 
RestartResponseAtInterceptPageException.InterceptData.set() is the URL to the 
LoginLink component itself, not to the Page which hosts it.  Specially, the URL 
captured looks like /site/home?0-1.ILinkListener-pnlLogin-lnkTwitterLogin-lnk 
whereas I would expect something more like /site/home.  In cases where the 
requested page already had page parameters, the ILinkListener bit as appended 
to existing parameters.

When the smoke clears, the user ends up at AccessDeniedPage under the 
ILinkListener URL rather than seeing the original page redisplayed.  Editing 
the URL to remove the query string at that point shows the home page as 
expected with the user properly authenticated.

Drilling in with the debugger a bit, it looks like 
RestartResponseAtInterceptPageException.InterceptData.set() calls 
RequestCycle.get().getRequest().getOriginalUrl() which eventually delegates 
down to ServletWebRequest.getUrl().  I can understand why that URL would 
reflect the LoginLink object as it's in the Link's onClick handler, but my 
expectation (and the behavior in 1.4.13) would be that the Page hosting the 
Link would be saved for the eventual continueToOriginalDestination() rather 
than the link to the component executing the handler.  I'm not sure if the 
AccessDenied is indicative of some other problem that might otherwise make this 
whole thing work properly, but it seems like a change in behavior at this point.


So…  Any advice would be appreciated.  If there's some more correct way to 
handle authentication via third party OAuth redirect, I'm certainly open to 
changing my code.

Thanks in advance,
Zac Bedell
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: RestartResponseAtInterceptPageException problem in 1.5

2012-01-02 Thread Martin Grigorov
Hi,

This behavior is by design.
I cannot say why AccessDeniedException is being thrown without
debugging it but I can suggest you to try:

LoginLink {
 onClick() {
  if (notLoggedIn) {
     throw new RestartResponseAtInterceptPageException(new
RedirectPage(getOAuthUrl()));
  }
 }

On Tue, Jan 3, 2012 at 2:04 AM, Zac Bedell zacl...@thebedells.org wrote:
 Greetings all,

 I've run into some trouble using RestartResponseAtInterceptPageException 
 since moving from Wicket 1.4.13 to 1.5.3.  The flow I'm implementing is a 
 login via an OAuth service, so the user is redirected by way of RedirectPage 
 to the OAuth provider and eventually ends up back at my site where 
 continueToOriginalDestination() would send them back to the original page.  
 The problem is that RestartResponseAtInterceptPageException is capturing the 
 URL to the Link object which triggers the login rather than the Page 
 containing the link, and the URL the user is eventually redirected to is 
 incorrect.  They end up with an AccessDeniedException rather than the 
 originally requested page.

 The Wicket object hierarchy looks like:

 MyBasePage extends WebPage {
  public MyBasePage() {
    add(new LoginLink(…));
  }
 }

 LoginLink {
  onClick() {
    throw new RestartResponseAtInterceptPageException(new 
 RedirectPage(getOAuthUrl()));
  }
 }

 // User clicks LoginLink on SomePage which extends MyBasePage, redirect to 
 OAuth provider works correctly, ends up back at:
 AuthCompletedPage extends WebPage {
  public AuthCompletedPage() {
    markSessionLoggedIn(…);
    continueToOriginalDestination();
  }
 }


 All of the redirect plumbing seems to work fine, but stepping through shows 
 that the URL captured in 
 RestartResponseAtInterceptPageException.InterceptData.set() is the URL to the 
 LoginLink component itself, not to the Page which hosts it.  Specially, the 
 URL captured looks like 
 /site/home?0-1.ILinkListener-pnlLogin-lnkTwitterLogin-lnk whereas I would 
 expect something more like /site/home.  In cases where the requested page 
 already had page parameters, the ILinkListener bit as appended to existing 
 parameters.

 When the smoke clears, the user ends up at AccessDeniedPage under the 
 ILinkListener URL rather than seeing the original page redisplayed.  
 Editing the URL to remove the query string at that point shows the home page 
 as expected with the user properly authenticated.

 Drilling in with the debugger a bit, it looks like 
 RestartResponseAtInterceptPageException.InterceptData.set() calls 
 RequestCycle.get().getRequest().getOriginalUrl() which eventually delegates 
 down to ServletWebRequest.getUrl().  I can understand why that URL would 
 reflect the LoginLink object as it's in the Link's onClick handler, but my 
 expectation (and the behavior in 1.4.13) would be that the Page hosting the 
 Link would be saved for the eventual continueToOriginalDestination() rather 
 than the link to the component executing the handler.  I'm not sure if the 
 AccessDenied is indicative of some other problem that might otherwise make 
 this whole thing work properly, but it seems like a change in behavior at 
 this point.


 So…  Any advice would be appreciated.  If there's some more correct way to 
 handle authentication via third party OAuth redirect, I'm certainly open to 
 changing my code.

 Thanks in advance,
 Zac Bedell
 -
 To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
 For additional commands, e-mail: users-h...@wicket.apache.org




-- 
Martin Grigorov
jWeekend
Training, Consulting, Development
http://jWeekend.com

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