wicket git commit: WICKET-4201 removing unnecessary runtime exception from PageProvider#doesProvideNewPage()

[pedro]

Repository: wicket
Updated Branches:
  refs/heads/WICKET-4201-improved-page-provider 1ec36a2e7 -> 0afd78c43


WICKET-4201 removing unnecessary runtime exception from 
PageProvider#doesProvideNewPage()


Project: http://git-wip-us.apache.org/repos/asf/wicket/repo
Commit: http://git-wip-us.apache.org/repos/asf/wicket/commit/0afd78c4
Tree: http://git-wip-us.apache.org/repos/asf/wicket/tree/0afd78c4
Diff: http://git-wip-us.apache.org/repos/asf/wicket/diff/0afd78c4

Branch: refs/heads/WICKET-4201-improved-page-provider
Commit: 0afd78c43409ec38428b4ab100547ac018913804
Parents: 1ec36a2
Author: Pedro Henrique Oliveira dos Santos 
Authored: Tue Feb 7 21:29:09 2017 -0200
Committer: Pedro Henrique Oliveira dos Santos 
Committed: Tue Feb 7 21:29:09 2017 -0200

--
 .../wicket/core/request/handler/PageProvider.java   |  4 
 .../apache/wicket/request/handler/PageProviderTest.java | 12 ++--
 2 files changed, 2 insertions(+), 14 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/wicket/blob/0afd78c4/wicket-core/src/main/java/org/apache/wicket/core/request/handler/PageProvider.java
--
diff --git 
a/wicket-core/src/main/java/org/apache/wicket/core/request/handler/PageProvider.java
 
b/wicket-core/src/main/java/org/apache/wicket/core/request/handler/PageProvider.java
index 5728628..dccd699 100644
--- 
a/wicket-core/src/main/java/org/apache/wicket/core/request/handler/PageProvider.java
+++ 
b/wicket-core/src/main/java/org/apache/wicket/core/request/handler/PageProvider.java
@@ -232,10 +232,6 @@ public class PageProvider implements IPageProvider, 
IClusterable
@Override
public final boolean doesProvideNewPage()
{
-   if (provision == null)
-   {
-   throw new IllegalStateException("Page instance not yet 
resolved");
-   }
return getProvision().doesProvideNewPage();
}
 

http://git-wip-us.apache.org/repos/asf/wicket/blob/0afd78c4/wicket-core/src/test/java/org/apache/wicket/request/handler/PageProviderTest.java
--
diff --git 
a/wicket-core/src/test/java/org/apache/wicket/request/handler/PageProviderTest.java
 
b/wicket-core/src/test/java/org/apache/wicket/request/handler/PageProviderTest.java
index f5af25a..622b48b 100644
--- 
a/wicket-core/src/test/java/org/apache/wicket/request/handler/PageProviderTest.java
+++ 
b/wicket-core/src/test/java/org/apache/wicket/request/handler/PageProviderTest.java
@@ -198,21 +198,13 @@ public class PageProviderTest extends WicketTestCase
public void testPageProperties_bookmarkable()
{
PageProvider provider = new 
PageProvider(StatelessPageTest.class);
+   assertTrue(provider.doesProvideNewPage());
assertFalse(provider.hasPageInstance());
-   try
-   {
-   provider.doesProvideNewPage();
-   fail("expected illegal state exception");
-   }
-   catch (IllegalStateException e)
-   {
-   // expected
-   }
 
provider.getPageInstance();
 
-   assertTrue(provider.hasPageInstance());
assertTrue(provider.doesProvideNewPage());
+   assertTrue(provider.hasPageInstance());
}
 
@Test

[jira] [Commented] (WICKET-4201) IPageProvider and its implementations need to be improved

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/WICKET-4201?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15857024#comment-15857024
 ] 

ASF subversion and git services commented on WICKET-4201:
-

Commit 0afd78c43409ec38428b4ab100547ac018913804 in wicket's branch 
refs/heads/WICKET-4201-improved-page-provider from Pedro Henrique Oliveira dos 
Santos
[ https://git-wip-us.apache.org/repos/asf?p=wicket.git;h=0afd78c ]

WICKET-4201 removing unnecessary runtime exception from 
PageProvider#doesProvideNewPage()


> IPageProvider and its implementations need to be improved
> -
>
> Key: WICKET-4201
> URL: https://issues.apache.org/jira/browse/WICKET-4201
> Project: Wicket
>  Issue Type: Task
>  Components: wicket
>Affects Versions: 1.5.0, 1.5.1, 1.5.2
>Reporter: Emond Papegaaij
>Assignee: Pedro Santos
>
> During the development op 1.5, IPageProvider and its implementations have 
> become a bit of a mess. The interface is not clearly defined. One of the 
> biggest problems is that several methods can throw exceptions and there is no 
> way of knowing which method will throw which exception and when. It should 
> always be clear what exceptions to expect. For example, getPage can throw a 
> PageExpiredException, but getPageClass cannot, it should return null if no 
> page class is set. Perhaps, it's even better to never throw exceptions at 
> all. Also, the various introspection methods are not very well defined and 
> make it almost impossible to come up with an alternative implementation of 
> the interface (which, IMHO is a sign of a broken API).
> Changing this interface is not an option for 1.5, but looking at the number 
> of subtle bugs that came from this part of the code, it should really be 
> considered for wicket.next.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (WICKET-4201) IPageProvider and its implementations need to be improved

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/WICKET-4201?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15856950#comment-15856950
 ] 

ASF subversion and git services commented on WICKET-4201:
-

Commit 1ec36a2e7efcd87655aedcffbc98d364960db0d9 in wicket's branch 
refs/heads/WICKET-4201-improved-page-provider from Pedro Henrique Oliveira dos 
Santos
[ https://git-wip-us.apache.org/repos/asf?p=wicket.git;h=1ec36a2 ]

WICKET-4201 better exception message


> IPageProvider and its implementations need to be improved
> -
>
> Key: WICKET-4201
> URL: https://issues.apache.org/jira/browse/WICKET-4201
> Project: Wicket
>  Issue Type: Task
>  Components: wicket
>Affects Versions: 1.5.0, 1.5.1, 1.5.2
>Reporter: Emond Papegaaij
>Assignee: Pedro Santos
>
> During the development op 1.5, IPageProvider and its implementations have 
> become a bit of a mess. The interface is not clearly defined. One of the 
> biggest problems is that several methods can throw exceptions and there is no 
> way of knowing which method will throw which exception and when. It should 
> always be clear what exceptions to expect. For example, getPage can throw a 
> PageExpiredException, but getPageClass cannot, it should return null if no 
> page class is set. Perhaps, it's even better to never throw exceptions at 
> all. Also, the various introspection methods are not very well defined and 
> make it almost impossible to come up with an alternative implementation of 
> the interface (which, IMHO is a sign of a broken API).
> Changing this interface is not an option for 1.5, but looking at the number 
> of subtle bugs that came from this part of the code, it should really be 
> considered for wicket.next.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

wicket git commit: WICKET-4201 better exception message

[pedro]

Repository: wicket
Updated Branches:
  refs/heads/WICKET-4201-improved-page-provider f7f5fb890 -> 1ec36a2e7


WICKET-4201 better exception message


Project: http://git-wip-us.apache.org/repos/asf/wicket/repo
Commit: http://git-wip-us.apache.org/repos/asf/wicket/commit/1ec36a2e
Tree: http://git-wip-us.apache.org/repos/asf/wicket/tree/1ec36a2e
Diff: http://git-wip-us.apache.org/repos/asf/wicket/diff/1ec36a2e

Branch: refs/heads/WICKET-4201-improved-page-provider
Commit: 1ec36a2e7efcd87655aedcffbc98d364960db0d9
Parents: f7f5fb8
Author: Pedro Henrique Oliveira dos Santos 
Authored: Tue Feb 7 20:43:46 2017 -0200
Committer: Pedro Henrique Oliveira dos Santos 
Committed: Tue Feb 7 20:43:46 2017 -0200

--
 .../java/org/apache/wicket/core/request/handler/PageProvider.java | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/wicket/blob/1ec36a2e/wicket-core/src/main/java/org/apache/wicket/core/request/handler/PageProvider.java
--
diff --git 
a/wicket-core/src/main/java/org/apache/wicket/core/request/handler/PageProvider.java
 
b/wicket-core/src/main/java/org/apache/wicket/core/request/handler/PageProvider.java
index 44e51cb..5728628 100644
--- 
a/wicket-core/src/main/java/org/apache/wicket/core/request/handler/PageProvider.java
+++ 
b/wicket-core/src/main/java/org/apache/wicket/core/request/handler/PageProvider.java
@@ -308,8 +308,7 @@ public class PageProvider implements IPageProvider, 
IClusterable
{
if (provision != null)
{
-   throw new IllegalStateException(
-   "A provision was already been done. The 
provider can be forcefully detached or a new one needs to be used to provide 
using this page source.");
+   throw new IllegalStateException("A page was already 
provided.");
}
this.pageSource = pageSource;
}

[jira] [Commented] (WICKET-5247) Broken Link in Tomcat because of Page Mount

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/WICKET-5247?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15856928#comment-15856928
 ] 

ASF GitHub Bot commented on WICKET-5247:


Github user martin-g commented on a diff in the pull request:

https://github.com/apache/wicket/pull/210#discussion_r99945970
  
--- Diff: 
wicket-core/src/test/java/org/apache/wicket/core/request/mapper/MountedMapperTest.java
 ---
@@ -714,7 +714,7 @@ public boolean isNewPageInstance()
@Test
public void placeholderEncode4()
{
-   PageProvider provider = new PageProvider(new MockPage())
+   PageProvider provider = new PageProvider(MockPage.class)
--- End diff --

I didn't understand you.
```java
/**
 * WICKET-5247 page instantiated without required parameters won't be 
mapped
 */
@Test
public void placeholderEncode4()
{
PageProvider provider = new PageProvider(new MockPage())
{
@Override
public boolean isNewPageInstance()
{
return false;
}
};
provider.setPageSource(context);
IRequestHandler handler = new 
RenderPageRequestHandler(provider);
Url url = placeholderEncoder.mapHandler(handler);
assertNull(url);
}
```
The test setups a PageProvider and uses it. There is no replacement after.
By making this change I think we don't test the same as what broke in 
WICKET-5247.


> Broken Link in Tomcat because of Page Mount
> ---
>
> Key: WICKET-5247
> URL: https://issues.apache.org/jira/browse/WICKET-5247
> Project: Wicket
>  Issue Type: Bug
>  Components: wicket-quickstart
>Affects Versions: 6.8.0
> Environment: Tomcat 7.0.41
>Reporter: Martin Wischnewski
>Assignee: Sven Meier
>Priority: Minor
> Fix For: 6.9.0, 1.5.11, 7.0.0-M1
>
> Attachments: quickstart.zip, webapp.war
>
>
> I post this message on the user mailing List 
> (http://apache-wicket.1842946.n4.nabble.com/Broken-Link-in-Tomcat-because-of-Page-Mount-tt4659663.html)
>  and Martin Grigorov asked me, to create a ticket on Jira.
> Broken Link in Tomcat because of Page Mount
> Following situation:
> -I have a Wicket Application(6.8.0) which runs under the context "webapp" on 
> a Tomcat 7.0.41
> -I mount a Page with two parameters (this is important) in the 
> WicketApplication.
>   mountPage("/mount/${parameter1}/${parameter2}", MountedPage.class);
> -The mounted Page(MountedPage.class) has only a simple Link
> -There are two links on the HomePage to the mounted Page.
>  They are declared as follows:
>  
>   add(new Link("link") {
>   @Override
>   public void onClick() {
>   setResponsePage(MountedPage.class, 
> linkParameters);
>   }
>   });
>   add(new Link("brokenLink") {
>   @Override
>   public void onClick() {
>   setResponsePage(new 
> MountedPage(linkParameters));
>   }
>   });
>   
> I deploy this Application as a war file on a Tomcat under the context 
> "webapp".
> When I call the first Link on the HomePage and then the Link on the mounted 
> Page, everything works fine.
> But if I call the second Link and then the Link on the mounted Page, the link 
> is broken.
> The context is missing in the generated link
>   http://localhost:8080/wicket/bookmarkable/com.mycompany.LinkedPage
> Does anyone have an idea, why the second link does not work on Tomcat?
> I add a Quickstart and the war file as attachment.
> Ps: Both links works fine in Jetty. 
> Pss:If I remove the mount command, both links will work in  Tomcat too.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (WICKET-6074) Use SHA 256+ for signing the release artefacts

[Martin Grigorov (JIRA)]

[ 
https://issues.apache.org/jira/browse/WICKET-6074?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15856897#comment-15856897
 ] 

Martin Grigorov commented on WICKET-6074:
-

Do we really need all kinds of sums ?

{code}
gpg --armor --detach-sign --use-agent --sign $f 
md5sum $f > $f.md5
sha256sum $f > $f.sha256
{code}
is enough.

> Use SHA 256+ for signing the release artefacts
> --
>
> Key: WICKET-6074
> URL: https://issues.apache.org/jira/browse/WICKET-6074
> Project: Wicket
>  Issue Type: Task
>  Components: release
>Affects Versions: 6.21.0, 7.2.0
>Reporter: Martin Grigorov
>
> See the discussion at dev@ about checking the release: 
> http://markmail.org/message/yu2f64rndmncseyd
> There are few issues:
> 1) It seems sha1sum is used. It will be better to use SHA 256+
> from release.sh:
> gpg --print-md SHA1 target/dist/apache-wicket-$version.tar.gz > 
> target/dist/apache-wicket-$version.tar.gz.sha
> 2) Drop .md5 ?!
> "man md5sum" says:
> BUGS
>The MD5 algorithm should not be used any more for security related 
> purposes.  Instead, better use an SHA-2 algorithm, implemented  in  the  
> programs  sha224sum(1),  sha256sum(1),  sha384sum(1),
>sha512sum(1)
> 3) use "sha256sum" instead of "gpg --print-md SHA1" to create the file to 
> make it simpler for checking later with "sha256sum -c"



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (WICKET-4201) IPageProvider and its implementations need to be improved

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/WICKET-4201?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15856856#comment-15856856
 ] 

ASF GitHub Bot commented on WICKET-4201:


Github user martin-g commented on a diff in the pull request:

https://github.com/apache/wicket/pull/210#discussion_r99936172
  
--- Diff: 
wicket-core/src/main/java/org/apache/wicket/core/request/handler/PageProvider.java
 ---
@@ -197,26 +194,49 @@ else if (isNewPageInstance() == false)
}
 
/**
-* The page instance is new only if there is no cached instance or the 
data stores doesn't have
-* a page with that id with the same {@linkplain #pageClass}.
-* 
-* @see IPageProvider#isNewPageInstance()
+* @return negates {@link PageProvider#hasPageInstance()}
+* @deprecated use {@link PageProvider#hasPageInstance()} negation 
instead
 */
@Override
public boolean isNewPageInstance()
{
-   boolean isNew = pageInstance == null;
-   if (isNew && pageId != null)
+   return !hasPageInstance();
+   }
+
+   /**
+* If this provider returns existing page, regardless if it was already 
created by PageProvider
+* itself or is or can be found in the data store. The only guarantee 
is that by calling
+* {@link PageProvider#getPageInstance()} this provider will return an 
existing instance and no
+* page will be created.
+* 
+* @return if provides an existing page
+*/
+   @Override
+   public final boolean hasPageInstance()
+   {
+   if (provision != null || pageId != null)
{
-   IRequestablePage storedPageInstance = 
getStoredPage(pageId);
-   if (storedPageInstance != null)
-   {
-   pageInstance = storedPageInstance;
-   isNew = false;
-   }
+   return getProvision().didResolveToPage();
}
+   else
+   return false;
+   }
 
-   return isNew;
+   /**
+* Returns whether or not the page instance held by this provider has 
been instantiated by the
+* provider.
+* 
+* @return {@code true} iff the page instance held by this provider was 
instantiated by the
+* provider
+*/
+   @Override
+   public final boolean doesProvideNewPage()
+   {
+   if (provision == null)
+   {
+   throw new IllegalStateException("Page instance not yet 
resolved");
--- End diff --

This doesn't look nice.
At 
https://issues.apache.org/jira/browse/WICKET-4201?focusedCommentId=15853108=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15853108
 you say 
 ` removed the PageExpiredException from PageProvider since it breaks the 
class coherence. It's designed to provide pages and related metadata (such as 
if the page was expired included), not to change the application flow on 
application exceptions.` but this runtime exception does exactly this.
IMO it would be better to return a three state result: `NEW`, `OLD` and 
`UNKNOWN`


> IPageProvider and its implementations need to be improved
> -
>
> Key: WICKET-4201
> URL: https://issues.apache.org/jira/browse/WICKET-4201
> Project: Wicket
>  Issue Type: Task
>  Components: wicket
>Affects Versions: 1.5.0, 1.5.1, 1.5.2
>Reporter: Emond Papegaaij
>Assignee: Pedro Santos
>
> During the development op 1.5, IPageProvider and its implementations have 
> become a bit of a mess. The interface is not clearly defined. One of the 
> biggest problems is that several methods can throw exceptions and there is no 
> way of knowing which method will throw which exception and when. It should 
> always be clear what exceptions to expect. For example, getPage can throw a 
> PageExpiredException, but getPageClass cannot, it should return null if no 
> page class is set. Perhaps, it's even better to never throw exceptions at 
> all. Also, the various introspection methods are not very well defined and 
> make it almost impossible to come up with an alternative implementation of 
> the interface (which, IMHO is a sign of a broken API).
> Changing this interface is not an option for 1.5, but looking at the number 
> of subtle bugs that came from this part of the code, it should really be 
> considered for wicket.next.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

wicket git commit: Added CHANGELOG for release 8.0.0-M4

[adelbene]

Repository: wicket
Updated Branches:
  refs/heads/master 5c9e27c6e -> a4a2ac6ef


Added CHANGELOG for release 8.0.0-M4


Project: http://git-wip-us.apache.org/repos/asf/wicket/repo
Commit: http://git-wip-us.apache.org/repos/asf/wicket/commit/a4a2ac6e
Tree: http://git-wip-us.apache.org/repos/asf/wicket/tree/a4a2ac6e
Diff: http://git-wip-us.apache.org/repos/asf/wicket/diff/a4a2ac6e

Branch: refs/heads/master
Commit: a4a2ac6ef5d9904dad0b2e510f0bf92cacd761fd
Parents: 5c9e27c
Author: Andrea Del Bene 
Authored: Fri Feb 3 21:55:50 2017 +0100
Committer: Andrea Del Bene 
Committed: Tue Feb 7 21:02:30 2017 +0100

--
 CHANGELOG-8.x | 27 +++
 1 file changed, 27 insertions(+)
--


http://git-wip-us.apache.org/repos/asf/wicket/blob/a4a2ac6e/CHANGELOG-8.x
--
diff --git a/CHANGELOG-8.x b/CHANGELOG-8.x
index 3b7c9a7..3d9d488 100644
--- a/CHANGELOG-8.x
+++ b/CHANGELOG-8.x
@@ -2,6 +2,33 @@ This file contains all changes done in releases for Apache 
Wicket 8.x.
 
 ===
 
+Release Notes - Wicket - Version 8.0.0-M4
+
+** Bug
+
+* [WICKET-6165] - Inconsistent behavior of Markupstream.hasMore vs. 
MarkupStream.next.
+* [WICKET-6288] - StatelessLink not working
+* [WICKET-6303] - renderHead method of a Behavior added to a Border body 
is not called
+* [WICKET-6306] - Changing model object of Panel added to a Border not 
allowed
+* [WICKET-6310] - Once invalidated the Session will be invalidated on 
every detach
+* [WICKET-6311] - SignOutPage_ru.html is missing
+* [WICKET-6314] - 7.6 release references 7.5-SNAPSHOT poms
+
+** Improvement
+
+* [WICKET-6307] - SubmitLink does not work in Chrome "ff.onsubmit is not a 
function"
+* [WICKET-6308] - Add an extra constructor to EmailTextField with a custom 
validator but without model
+* [WICKET-6315] - Optimize LinkParser by caching the compiled regex Pattern
+
+** Task
+
+* [WICKET-6287] - Switch from json.org to open-json
+* [WICKET-6304] - Remove Tomcat7 support in Native WebSockets
+* [WICKET-6305] - Remove Atmosphere module
+* [WICKET-6309] - Move the Native WebSocket demo to wicket-examples module
+
+===
+
 Release Notes - Wicket - Version 8.0.0-M3
 
 ** Bug

svn commit: r18211 - /release/wicket/8.0.0-M3/

[adelbene]

Author: adelbene
Date: Tue Feb  7 19:48:49 2017
New Revision: 18211

Log:
Removed previous milestone

Removed:
release/wicket/8.0.0-M3/

[wicket] Git Push Summary

[adelbene]

Repository: wicket
Updated Tags:  refs/tags/rel/wicket-8.0.0-M4 [created] ee4b06f03

svn commit: r18209 - /dev/wicket/8.0.0-M4/ /release/wicket/8.0.0-M4/

[adelbene]

Author: adelbene
Date: Tue Feb  7 19:03:35 2017
New Revision: 18209

Log:
Upload release to the mirrors

Added:
release/wicket/8.0.0-M4/
  - copied from r18208, dev/wicket/8.0.0-M4/
Removed:
dev/wicket/8.0.0-M4/

[jira] [Commented] (WICKET-6317) AuthenticatedWebSession#signOut() calls twice after session invalidation

[Alexey Prudnikov (JIRA)]

[ 
https://issues.apache.org/jira/browse/WICKET-6317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15855908#comment-15855908
 ] 

Alexey Prudnikov commented on WICKET-6317:
--

Martin, thank you! I already refactor my business code so it doesn't afraid of 
multiple signOut() calls now, but your tip still very useful!

> AuthenticatedWebSession#signOut() calls twice after session invalidation
> 
>
> Key: WICKET-6317
> URL: https://issues.apache.org/jira/browse/WICKET-6317
> Project: Wicket
>  Issue Type: Bug
>  Components: wicket, wicket-auth-roles
>Affects Versions: 7.6.0
>Reporter: Alexey Prudnikov
>
> When the user wants to log out, I call AuthenticatedWebSession#invalidate(), 
> which, in turn, calls AuthenticatedWebSession#signOut() and sets 
> Session#sessionInvalidated to true.
> After that, at the end of request processing, RequestCycle#onDetach() is 
> called, which in turn calls Session#detach(). The last method checks 
> Session#sessionInvalidated state, and because it is true, invalidates session 
> again with Session#invalidateNow().
> So, if I place some business logic code in #signOut() (as in example class 
> BasicAuthenticationSession from [official 
> guide|https://ci.apache.org/projects/wicket/guide/7.x/single.html#_using_roles_with_metadata]),
>  this code also calls twice, which may be inappropriate in some cases.
> I know about WICKET-6228 ticket - now #invalidate() doesn't call #signOut(), 
> and this can be solution for issue, but that changes not ported to Wicket 7 
> branch.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (WICKET-6317) AuthenticatedWebSession#signOut() calls twice after session invalidation

[Martin Grigorov (JIRA)]

[ 
https://issues.apache.org/jira/browse/WICKET-6317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15855884#comment-15855884
 ] 

Martin Grigorov commented on WICKET-6317:
-

OK, I see. We should not call invalidate() in invalidateNow() if the session is 
already invalidated.
You can do the same in your signOut() in the meantime, just wrap your logic 
with "if (!isSessionInvalidated()) { your logic here }".

> AuthenticatedWebSession#signOut() calls twice after session invalidation
> 
>
> Key: WICKET-6317
> URL: https://issues.apache.org/jira/browse/WICKET-6317
> Project: Wicket
>  Issue Type: Bug
>  Components: wicket, wicket-auth-roles
>Affects Versions: 7.6.0
>Reporter: Alexey Prudnikov
>
> When the user wants to log out, I call AuthenticatedWebSession#invalidate(), 
> which, in turn, calls AuthenticatedWebSession#signOut() and sets 
> Session#sessionInvalidated to true.
> After that, at the end of request processing, RequestCycle#onDetach() is 
> called, which in turn calls Session#detach(). The last method checks 
> Session#sessionInvalidated state, and because it is true, invalidates session 
> again with Session#invalidateNow().
> So, if I place some business logic code in #signOut() (as in example class 
> BasicAuthenticationSession from [official 
> guide|https://ci.apache.org/projects/wicket/guide/7.x/single.html#_using_roles_with_metadata]),
>  this code also calls twice, which may be inappropriate in some cases.
> I know about WICKET-6228 ticket - now #invalidate() doesn't call #signOut(), 
> and this can be solution for issue, but that changes not ported to Wicket 7 
> branch.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (WICKET-6317) AuthenticatedWebSession#signOut() calls twice after session invalidation

[Alexey Prudnikov (JIRA)]

[ 
https://issues.apache.org/jira/browse/WICKET-6317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15855869#comment-15855869
 ] 

Alexey Prudnikov commented on WICKET-6317:
--

Thank you for quick response!

I realize that changes from WICKET-6228 is API break, no doubt about it.

But I didn't understand about 7.x branch - it is my incorrect implementation 
(probably because of the mistake in documentation) or bug? If it is the 
incorrect implementation, what is the right way to process user logout with 
some application-specific business rules?

> AuthenticatedWebSession#signOut() calls twice after session invalidation
> 
>
> Key: WICKET-6317
> URL: https://issues.apache.org/jira/browse/WICKET-6317
> Project: Wicket
>  Issue Type: Bug
>  Components: wicket, wicket-auth-roles
>Affects Versions: 7.6.0
>Reporter: Alexey Prudnikov
>
> When the user wants to log out, I call AuthenticatedWebSession#invalidate(), 
> which, in turn, calls AuthenticatedWebSession#signOut() and sets 
> Session#sessionInvalidated to true.
> After that, at the end of request processing, RequestCycle#onDetach() is 
> called, which in turn calls Session#detach(). The last method checks 
> Session#sessionInvalidated state, and because it is true, invalidates session 
> again with Session#invalidateNow().
> So, if I place some business logic code in #signOut() (as in example class 
> BasicAuthenticationSession from [official 
> guide|https://ci.apache.org/projects/wicket/guide/7.x/single.html#_using_roles_with_metadata]),
>  this code also calls twice, which may be inappropriate in some cases.
> I know about WICKET-6228 ticket - now #invalidate() doesn't call #signOut(), 
> and this can be solution for issue, but that changes not ported to Wicket 7 
> branch.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (WICKET-6317) AuthenticatedWebSession#signOut() calls twice after session invalidation

[Martin Grigorov (JIRA)]

[ 
https://issues.apache.org/jira/browse/WICKET-6317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15855848#comment-15855848
 ] 

Martin Grigorov commented on WICKET-6317:
-

WICKET-6228 is not applied to 7.x because it might break (silently) 
applications in production.
There is an entry in the migration guide for 8.x about it so hopefully the 
developers will take it into account.

We should definitely improve the example in the guide!

Thank you!

> AuthenticatedWebSession#signOut() calls twice after session invalidation
> 
>
> Key: WICKET-6317
> URL: https://issues.apache.org/jira/browse/WICKET-6317
> Project: Wicket
>  Issue Type: Bug
>  Components: wicket, wicket-auth-roles
>Affects Versions: 7.6.0
>Reporter: Alexey Prudnikov
>
> When the user wants to log out, I call AuthenticatedWebSession#invalidate(), 
> which, in turn, calls AuthenticatedWebSession#signOut() and sets 
> Session#sessionInvalidated to true.
> After that, at the end of request processing, RequestCycle#onDetach() is 
> called, which in turn calls Session#detach(). The last method checks 
> Session#sessionInvalidated state, and because it is true, invalidates session 
> again with Session#invalidateNow().
> So, if I place some business logic code in #signOut() (as in example class 
> BasicAuthenticationSession from [official 
> guide|https://ci.apache.org/projects/wicket/guide/7.x/single.html#_using_roles_with_metadata]),
>  this code also calls twice, which may be inappropriate in some cases.
> I know about WICKET-6228 ticket - now #invalidate() doesn't call #signOut(), 
> and this can be solution for issue, but that changes not ported to Wicket 7 
> branch.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (WICKET-6317) AuthenticatedWebSession#signOut() calls twice after session invalidation

[Alexey Prudnikov (JIRA)]

Alexey Prudnikov created WICKET-6317:


 Summary: AuthenticatedWebSession#signOut() calls twice after 
session invalidation
 Key: WICKET-6317
 URL: https://issues.apache.org/jira/browse/WICKET-6317
 Project: Wicket
  Issue Type: Bug
  Components: wicket, wicket-auth-roles
Affects Versions: 7.6.0
Reporter: Alexey Prudnikov


When the user wants to log out, I call AuthenticatedWebSession#invalidate(), 
which, in turn, calls AuthenticatedWebSession#signOut() and sets 
Session#sessionInvalidated to true.

After that, at the end of request processing, RequestCycle#onDetach() is 
called, which in turn calls Session#detach(). The last method checks 
Session#sessionInvalidated state, and because it is true, invalidates session 
again with Session#invalidateNow().

So, if I place some business logic code in #signOut() (as in example class 
BasicAuthenticationSession from [official 
guide|https://ci.apache.org/projects/wicket/guide/7.x/single.html#_using_roles_with_metadata]),
 this code also calls twice, which may be inappropriate in some cases.

I know about WICKET-6228 ticket - now #invalidate() doesn't call #signOut(), 
and this can be solution for issue, but that changes not ported to Wicket 7 
branch.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (WICKET-6074) Use SHA 256+ for signing the release artefacts

[Maxim Solodovnik (JIRA)]

[ 
https://issues.apache.org/jira/browse/WICKET-6074?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15855709#comment-15855709
 ] 

Maxim Solodovnik commented on WICKET-6074:
--

OK with me :)
I'm not sure why to keep $f.gpg*

> Use SHA 256+ for signing the release artefacts
> --
>
> Key: WICKET-6074
> URL: https://issues.apache.org/jira/browse/WICKET-6074
> Project: Wicket
>  Issue Type: Task
>  Components: release
>Affects Versions: 6.21.0, 7.2.0
>Reporter: Martin Grigorov
>
> See the discussion at dev@ about checking the release: 
> http://markmail.org/message/yu2f64rndmncseyd
> There are few issues:
> 1) It seems sha1sum is used. It will be better to use SHA 256+
> from release.sh:
> gpg --print-md SHA1 target/dist/apache-wicket-$version.tar.gz > 
> target/dist/apache-wicket-$version.tar.gz.sha
> 2) Drop .md5 ?!
> "man md5sum" says:
> BUGS
>The MD5 algorithm should not be used any more for security related 
> purposes.  Instead, better use an SHA-2 algorithm, implemented  in  the  
> programs  sha224sum(1),  sha256sum(1),  sha384sum(1),
>sha512sum(1)
> 3) use "sha256sum" instead of "gpg --print-md SHA1" to create the file to 
> make it simpler for checking later with "sha256sum -c"



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (WICKET-6074) Use SHA 256+ for signing the release artefacts

[Martijn Dashorst (JIRA)]

[ 
https://issues.apache.org/jira/browse/WICKET-6074?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15855650#comment-15855650
 ] 

Martijn Dashorst commented on WICKET-6074:
--

First of all, you should verify the release by the GPG signed signature:

{{code}}
gpg --verify apache-wicket-*.tar.gz.asc
{{code}}

Now for the md5 and sha1 sums, I agree that the gpg format is strange due to 
the extra new line between the path and checksum. We should at least change the 
release script to pushd and popd to the dist folder before generating the 
signatures, this will eliminate the target/dist/ from the path and the 
extraneous new line.

Then it is just a 
{{code}}
gpg --print-md MD5 apache-wicket-8.0.0-M4.tar.gz | diff 
apache-wicket-8.0.0-M4.tar.gz.md5 -
{{code}}

away to verify the release. We can *also* change the extension of the gpg 
message digest to .gpgmd5 and add md5sum signatures for BSD like verification.

I propose the following change to the release script:

{{code}}
pushd target/dist

for f in apache*.{gz,zip}
do
gpg --armor --detach-sign --use-agent --sign $f 
gpg --print-md SHA1 $f > $f.gpgsha1
gpg --print-md MD5 $f > $f.gpgmd5
md5sum $f > $f.md5
sha1sum $f > $f.sha1
sha256sum $f > $f.sha256
done

popd
{{code}}

and do the same for the convenience binaries.

> Use SHA 256+ for signing the release artefacts
> --
>
> Key: WICKET-6074
> URL: https://issues.apache.org/jira/browse/WICKET-6074
> Project: Wicket
>  Issue Type: Task
>  Components: release
>Affects Versions: 6.21.0, 7.2.0
>Reporter: Martin Grigorov
>
> See the discussion at dev@ about checking the release: 
> http://markmail.org/message/yu2f64rndmncseyd
> There are few issues:
> 1) It seems sha1sum is used. It will be better to use SHA 256+
> from release.sh:
> gpg --print-md SHA1 target/dist/apache-wicket-$version.tar.gz > 
> target/dist/apache-wicket-$version.tar.gz.sha
> 2) Drop .md5 ?!
> "man md5sum" says:
> BUGS
>The MD5 algorithm should not be used any more for security related 
> purposes.  Instead, better use an SHA-2 algorithm, implemented  in  the  
> programs  sha224sum(1),  sha256sum(1),  sha384sum(1),
>sha512sum(1)
> 3) use "sha256sum" instead of "gpg --print-md SHA1" to create the file to 
> make it simpler for checking later with "sha256sum -c"



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Comment Edited] (WICKET-6074) Use SHA 256+ for signing the release artefacts

[Martijn Dashorst (JIRA)]

[ 
https://issues.apache.org/jira/browse/WICKET-6074?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15855650#comment-15855650
 ] 

Martijn Dashorst edited comment on WICKET-6074 at 2/7/17 9:43 AM:
--

First of all, you should verify the release by the GPG signed signature:

{code}
gpg --verify apache-wicket-*.tar.gz.asc
{code}

Now for the md5 and sha1 sums, I agree that the gpg format is strange due to 
the extra new line between the path and checksum. We should at least change the 
release script to pushd and popd to the dist folder before generating the 
signatures, this will eliminate the target/dist/ from the path and the 
extraneous new line.

Then it is just a 
{{code}}
gpg --print-md MD5 apache-wicket-8.0.0-M4.tar.gz | diff 
apache-wicket-8.0.0-M4.tar.gz.md5 -
{{code}}

away to verify the release. We can *also* change the extension of the gpg 
message digest to .gpgmd5 and add md5sum signatures for BSD like verification.

I propose the following change to the release script:

{{code}}
pushd target/dist

for f in apache*.{gz,zip}
do
gpg --armor --detach-sign --use-agent --sign $f 
gpg --print-md SHA1 $f > $f.gpgsha1
gpg --print-md MD5 $f > $f.gpgmd5
md5sum $f > $f.md5
sha1sum $f > $f.sha1
sha256sum $f > $f.sha256
done

popd
{{code}}

and do the same for the convenience binaries.


was (Author: dashorst):
First of all, you should verify the release by the GPG signed signature:

{{code}}
gpg --verify apache-wicket-*.tar.gz.asc
{{code}}

Now for the md5 and sha1 sums, I agree that the gpg format is strange due to 
the extra new line between the path and checksum. We should at least change the 
release script to pushd and popd to the dist folder before generating the 
signatures, this will eliminate the target/dist/ from the path and the 
extraneous new line.

Then it is just a 
{{code}}
gpg --print-md MD5 apache-wicket-8.0.0-M4.tar.gz | diff 
apache-wicket-8.0.0-M4.tar.gz.md5 -
{{code}}

away to verify the release. We can *also* change the extension of the gpg 
message digest to .gpgmd5 and add md5sum signatures for BSD like verification.

I propose the following change to the release script:

{{code}}
pushd target/dist

for f in apache*.{gz,zip}
do
gpg --armor --detach-sign --use-agent --sign $f 
gpg --print-md SHA1 $f > $f.gpgsha1
gpg --print-md MD5 $f > $f.gpgmd5
md5sum $f > $f.md5
sha1sum $f > $f.sha1
sha256sum $f > $f.sha256
done

popd
{{code}}

and do the same for the convenience binaries.

> Use SHA 256+ for signing the release artefacts
> --
>
> Key: WICKET-6074
> URL: https://issues.apache.org/jira/browse/WICKET-6074
> Project: Wicket
>  Issue Type: Task
>  Components: release
>Affects Versions: 6.21.0, 7.2.0
>Reporter: Martin Grigorov
>
> See the discussion at dev@ about checking the release: 
> http://markmail.org/message/yu2f64rndmncseyd
> There are few issues:
> 1) It seems sha1sum is used. It will be better to use SHA 256+
> from release.sh:
> gpg --print-md SHA1 target/dist/apache-wicket-$version.tar.gz > 
> target/dist/apache-wicket-$version.tar.gz.sha
> 2) Drop .md5 ?!
> "man md5sum" says:
> BUGS
>The MD5 algorithm should not be used any more for security related 
> purposes.  Instead, better use an SHA-2 algorithm, implemented  in  the  
> programs  sha224sum(1),  sha256sum(1),  sha384sum(1),
>sha512sum(1)
> 3) use "sha256sum" instead of "gpg --print-md SHA1" to create the file to 
> make it simpler for checking later with "sha256sum -c"



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Comment Edited] (WICKET-6074) Use SHA 256+ for signing the release artefacts

[Martijn Dashorst (JIRA)]

[ 
https://issues.apache.org/jira/browse/WICKET-6074?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15855650#comment-15855650
 ] 

Martijn Dashorst edited comment on WICKET-6074 at 2/7/17 9:43 AM:
--

First of all, you should verify the release by the GPG signed signature:

{code}
gpg --verify apache-wicket-*.tar.gz.asc
{code}

Now for the md5 and sha1 sums, I agree that the gpg format is strange due to 
the extra new line between the path and checksum. We should at least change the 
release script to pushd and popd to the dist folder before generating the 
signatures, this will eliminate the target/dist/ from the path and the 
extraneous new line.

Then it is just a 
{code}
gpg --print-md MD5 apache-wicket-8.0.0-M4.tar.gz | diff 
apache-wicket-8.0.0-M4.tar.gz.md5 -
{code}

away to verify the release. We can *also* change the extension of the gpg 
message digest to .gpgmd5 and add md5sum signatures for BSD like verification.

I propose the following change to the release script:

{code}
pushd target/dist

for f in apache*.{gz,zip}
do
gpg --armor --detach-sign --use-agent --sign $f 
gpg --print-md SHA1 $f > $f.gpgsha1
gpg --print-md MD5 $f > $f.gpgmd5
md5sum $f > $f.md5
sha1sum $f > $f.sha1
sha256sum $f > $f.sha256
done

popd
{code}

and do the same for the convenience binaries.


was (Author: dashorst):
First of all, you should verify the release by the GPG signed signature:

{code}
gpg --verify apache-wicket-*.tar.gz.asc
{code}

Now for the md5 and sha1 sums, I agree that the gpg format is strange due to 
the extra new line between the path and checksum. We should at least change the 
release script to pushd and popd to the dist folder before generating the 
signatures, this will eliminate the target/dist/ from the path and the 
extraneous new line.

Then it is just a 
{{code}}
gpg --print-md MD5 apache-wicket-8.0.0-M4.tar.gz | diff 
apache-wicket-8.0.0-M4.tar.gz.md5 -
{{code}}

away to verify the release. We can *also* change the extension of the gpg 
message digest to .gpgmd5 and add md5sum signatures for BSD like verification.

I propose the following change to the release script:

{{code}}
pushd target/dist

for f in apache*.{gz,zip}
do
gpg --armor --detach-sign --use-agent --sign $f 
gpg --print-md SHA1 $f > $f.gpgsha1
gpg --print-md MD5 $f > $f.gpgmd5
md5sum $f > $f.md5
sha1sum $f > $f.sha1
sha256sum $f > $f.sha256
done

popd
{{code}}

and do the same for the convenience binaries.

> Use SHA 256+ for signing the release artefacts
> --
>
> Key: WICKET-6074
> URL: https://issues.apache.org/jira/browse/WICKET-6074
> Project: Wicket
>  Issue Type: Task
>  Components: release
>Affects Versions: 6.21.0, 7.2.0
>Reporter: Martin Grigorov
>
> See the discussion at dev@ about checking the release: 
> http://markmail.org/message/yu2f64rndmncseyd
> There are few issues:
> 1) It seems sha1sum is used. It will be better to use SHA 256+
> from release.sh:
> gpg --print-md SHA1 target/dist/apache-wicket-$version.tar.gz > 
> target/dist/apache-wicket-$version.tar.gz.sha
> 2) Drop .md5 ?!
> "man md5sum" says:
> BUGS
>The MD5 algorithm should not be used any more for security related 
> purposes.  Instead, better use an SHA-2 algorithm, implemented  in  the  
> programs  sha224sum(1),  sha256sum(1),  sha384sum(1),
>sha512sum(1)
> 3) use "sha256sum" instead of "gpg --print-md SHA1" to create the file to 
> make it simpler for checking later with "sha256sum -c"



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)