[jira] [Commented] (WICKET-6702) AsynchronousPageStore with NotDetachedModelChecker - "Not detached model found" exception on several fast sequential Ajax calls
[ https://issues.apache.org/jira/browse/WICKET-6702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16935871#comment-16935871 ] Martin Grigorov commented on WICKET-6702: - Please attach a complete application. Maven based is preferred. See [http://wicket.apache.org/start/quickstart.html] > AsynchronousPageStore with NotDetachedModelChecker - "Not detached model > found" exception on several fast sequential Ajax calls > --- > > Key: WICKET-6702 > URL: https://issues.apache.org/jira/browse/WICKET-6702 > Project: Wicket > Issue Type: Bug > Components: wicket-core >Affects Versions: 8.5.0 >Reporter: Sergei Tkachuk >Priority: Major > Attachments: SerializationProblemPage.html, > SerializationProblemPage.java, SerializationProblemPage.log, > TestSerializationProblemPage.java > > > Preconditions: Application uses AsynchronousPageStore (as it is by default). > When there are several fast sequential Ajax calls to a component, then a > component's LoadableDetachableModel gets attached and detached several times > before real async serialization takes place. And at times the serialization > is initiated when the model has been already attached once again by a > subsequent Ajax call, and not detached yet as the request is still in > progress. This causes NotDetachedModelChecker() to throw "Not detached model > found!" exception > Disabling async serialization fixes the problem. > A test-case and a log attached. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (WICKET-6698) Non-security critical dependency updates
[ https://issues.apache.org/jira/browse/WICKET-6698?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Grigorov resolved WICKET-6698. - Fix Version/s: 9.0.0-M3 8.7.0 Assignee: Martin Grigorov Resolution: Fixed > Non-security critical dependency updates > > > Key: WICKET-6698 > URL: https://issues.apache.org/jira/browse/WICKET-6698 > Project: Wicket > Issue Type: Task > Components: wicket >Affects Versions: 8.5.0 >Reporter: Matt Pavlovich >Assignee: Martin Grigorov >Priority: Major > Fix For: 8.7.0, 9.0.0-M3 > > > openjson: 1.0.10 to 1.0.11 > commons-collectections4: 4.3 to 4.4 > jackson: 2.9.8 to 2.9.9 > jdk-serializable-functional: 1.8.5 to 1.8.6 -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Resolved] (WICKET-6536) Add generic to MarkupContainer#visitChildren
[
https://issues.apache.org/jira/browse/WICKET-6536?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Grigorov resolved WICKET-6536.
-
Assignee: Martin Grigorov (was: Sven Meier)
Resolution: Won't Fix
Closing as "Won't fix" because this change would lead to different need for
casting.
Very often this method is used not to find `AjaxButton` (or other specific
Component) but MyInterface, i.e. a business interface class that some
components may implement. In the visit() method the results are usually casted
to Component/MarkupContainer and their getId(), isVisible(), etc. methods are
used.
With the proposed change the type would be MyInterface instead of Object but
the application code will still need to cast to Component most of the time.
I don't see a compelling reason to break the API here.
> Add generic to MarkupContainer#visitChildren
>
>
> Key: WICKET-6536
> URL: https://issues.apache.org/jira/browse/WICKET-6536
> Project: Wicket
> Issue Type: Improvement
> Components: wicket
>Affects Versions: 8.0.0-M8
>Reporter: Kamil
>Assignee: Martin Grigorov
>Priority: Major
>
> currently MarkupContainer#visitChildren has signature:
> {code:java}
> final R visitChildren(final Class clazz, final
> IVisitor visitor){code}
> while im my opinion it should have:
> {code:java}
> final R visitChildren(final Class clazz, final
> IVisitor visitor){code}
> Why force user to do class cast while we already know which class we pass to
> the method?
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Commented] (WICKET-3404) Improve ModalWindow form handling
[ https://issues.apache.org/jira/browse/WICKET-3404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16911449#comment-16911449 ] Martin Grigorov commented on WICKET-3404: - Related to WICKET- > Improve ModalWindow form handling > - > > Key: WICKET-3404 > URL: https://issues.apache.org/jira/browse/WICKET-3404 > Project: Wicket > Issue Type: Improvement > Components: wicket-extensions >Affects Versions: 1.5-RC1 >Reporter: Sven Meier >Assignee: Sven Meier >Priority: Major > Attachments: ModalWindow.patch, ModalWindow_v2.patch > > > Currently ModalWindow's javascript generates a generic tag into the > page. > This is done to support nested forms while preventing temporary invalid HTML > markup in the browser, i.e. a form nested in a another form. > IMHO this is rather inelegant, which manifests itself in the following note > in ModalWindow's javadoc: > "If you want to use form in modal window component make sure that you put the > modal window itself in another form (nesting forms is legal in Wicket) ..." > I'm always having a hard time to explain this sentence to Wicket newcomers. > My proposal: Let go of the tag in javascript with the attached patch! > The changed code now adds ModalWindow's markup first into the HTML page and > then replaces its content *directly* with the component's markup to show in > the modal window (the current implementation does it the other way around). > The proposed change would require a migration effort for some usages of > ModalWindow though. Forms inside a ModalWindow inside another form have to be > 'made root forms', either by overriding isRootForm() and getRootForm() or > perhaps we could introduce a new interface (e.g. IFormSeparator) which > signals to a form that its containment in another form doesn't make it a > nested form. > Note that this issue is not about esthetics only, we have reocurring usecases > in our projects (a form inside a modal window inside another *multipart* > form) which require quirks to make it work. I can provide more information on > this if required. > Further note that even standard form submits are now possible on ModalWindows > too (might be interesting for multipart uploads directly initiated from a > ModalWindow's form). -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Resolved] (WICKET-6694) Let's manage the javascript of AutoLabelMarker when there is a error on formComponent
[
https://issues.apache.org/jira/browse/WICKET-6694?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Grigorov resolved WICKET-6694.
-
Resolution: Won't Fix
> Let's manage the javascript of AutoLabelMarker when there is a error on
> formComponent
> -
>
> Key: WICKET-6694
> URL: https://issues.apache.org/jira/browse/WICKET-6694
> Project: Wicket
> Issue Type: Improvement
> Components: wicket-core
>Affects Versions: 8.5.0
> Environment: Windows 10, java 8
>Reporter: Duto
>Priority: Trivial
> Attachments: error_field.png
>
>
> Hello,
> It will be very nice, if we could modify the javascript
> '_Wicket.DOM.toggleClass('%s', '%s', %s);_' of AutoLabelMarker when there is
> an error on composant.
> I use fomantic UI for css library and when a field has an error I need to set
> the error class not to the label but to a closest of label/component :
>
> like this :
> {{}}
> {{ name}}
> {{}}{{}}
> Best regards
> Duto
>
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Commented] (WICKET-6694) Let's manage the javascript of AutoLabelMarker when there is a error on formComponent
[
https://issues.apache.org/jira/browse/WICKET-6694?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16911448#comment-16911448
]
Martin Grigorov commented on WICKET-6694:
-
You have marked this issue as Trivial but it is far from trivial.
`wicket:for` attribute creates an auto-component, i.e. a Component is being
added to the component tree without calling `MarkupContainer#add(...)` and
without `wicket:id` in the markup. The application code has no access to this
auto-component at all! So even if the method that appends
`Wicket.DOM.toggleClass()` is made protected/overridable (this is not possible
in 8.x due to binary API break) your application code still won't be able to
override it because it doesn't instantiate it in first place.
You need to use a proper/non-auto component, e.g. WebMarkupContainer, on the
`` which class you need to manipulate.
`wicket:for` is handy for _most_ of the cases, but not in yours.
> Let's manage the javascript of AutoLabelMarker when there is a error on
> formComponent
> -
>
> Key: WICKET-6694
> URL: https://issues.apache.org/jira/browse/WICKET-6694
> Project: Wicket
> Issue Type: Improvement
> Components: wicket-core
>Affects Versions: 8.5.0
> Environment: Windows 10, java 8
>Reporter: Duto
>Priority: Trivial
> Attachments: error_field.png
>
>
> Hello,
> It will be very nice, if we could modify the javascript
> '_Wicket.DOM.toggleClass('%s', '%s', %s);_' of AutoLabelMarker when there is
> an error on composant.
> I use fomantic UI for css library and when a field has an error I need to set
> the error class not to the label but to a closest of label/component :
>
> like this :
> {{}}
> {{ name}}
> {{}}{{}}
> Best regards
> Duto
>
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Resolved] (WICKET-6692) Page deserialization on websocket close - possible performance issue
[
https://issues.apache.org/jira/browse/WICKET-6692?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Grigorov resolved WICKET-6692.
-
Resolution: Fixed
Fix Version/s: 9.0.0-M3
8.6.0
> Page deserialization on websocket close - possible performance issue
>
>
> Key: WICKET-6692
> URL: https://issues.apache.org/jira/browse/WICKET-6692
> Project: Wicket
> Issue Type: Bug
> Components: wicket-native-websocket
>Affects Versions: 6.30.0, 8.5.0
>Reporter: Daniel Stoch
>Assignee: Martin Grigorov
>Priority: Major
> Fix For: 8.6.0, 9.0.0-M3
>
> Attachments: websocket-deser-onclose.zip
>
>
> We have a page with websocket connection (using WebSocketBehavior). When user
> navigates to another page, a websocket connection is closed and
> AbstractWebSocketProcessor.onClose method is called. This causes broadcasting
> a message to connected page:
> {code}
> broadcastMessage(new ClosedMessage(getApplication(), getSessionId(), key));
> {code}
> and leads to page deserialisation (from PageStore).
> I wonder how it can affect performance: almost every page navigation causes
> page deserialization (when it should occur only for back button or when some
> websocket message comes and application need to process it).
>
> Maybe this message should be send only when needed or maybe I should not care
> and current behaviour does not affect performance?
>
> I have attached a simple quick start:
> - click links to navigate between pages: “Nav 1” and “Home”,
> - after each click you can see “>> Closed message: …” on System.out (so
> closed message was sent),
> - AbstractWebSocketProcessor broadcast a ClosedMessage to a page, which
> causes its deserialization (you can debug IPageStore.getPage call).
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Comment Edited] (WICKET-6692) Page deserialization on websocket close - possible performance issue
[
https://issues.apache.org/jira/browse/WICKET-6692?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16907227#comment-16907227
]
Martin Grigorov edited comment on WICKET-6692 at 8/14/19 12:26 PM:
---
Sorry, but Wicket 6.x receives only security related fixes.
was (Author: mgrigorov):
Sorry, but Wicket 6.x received only security related fixes.
> Page deserialization on websocket close - possible performance issue
>
>
> Key: WICKET-6692
> URL: https://issues.apache.org/jira/browse/WICKET-6692
> Project: Wicket
> Issue Type: Bug
> Components: wicket-native-websocket
>Affects Versions: 6.30.0, 8.5.0
>Reporter: Daniel Stoch
>Assignee: Martin Grigorov
>Priority: Major
> Attachments: websocket-deser-onclose.zip
>
>
> We have a page with websocket connection (using WebSocketBehavior). When user
> navigates to another page, a websocket connection is closed and
> AbstractWebSocketProcessor.onClose method is called. This causes broadcasting
> a message to connected page:
> {code}
> broadcastMessage(new ClosedMessage(getApplication(), getSessionId(), key));
> {code}
> and leads to page deserialisation (from PageStore).
> I wonder how it can affect performance: almost every page navigation causes
> page deserialization (when it should occur only for back button or when some
> websocket message comes and application need to process it).
>
> Maybe this message should be send only when needed or maybe I should not care
> and current behaviour does not affect performance?
>
> I have attached a simple quick start:
> - click links to navigate between pages: “Nav 1” and “Home”,
> - after each click you can see “>> Closed message: …” on System.out (so
> closed message was sent),
> - AbstractWebSocketProcessor broadcast a ClosedMessage to a page, which
> causes its deserialization (you can debug IPageStore.getPage call).
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Commented] (WICKET-6692) Page deserialization on websocket close - possible performance issue
[
https://issues.apache.org/jira/browse/WICKET-6692?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16907227#comment-16907227
]
Martin Grigorov commented on WICKET-6692:
-
Sorry, but Wicket 6.x received only security related fixes.
> Page deserialization on websocket close - possible performance issue
>
>
> Key: WICKET-6692
> URL: https://issues.apache.org/jira/browse/WICKET-6692
> Project: Wicket
> Issue Type: Bug
> Components: wicket-native-websocket
>Affects Versions: 6.30.0, 8.5.0
>Reporter: Daniel Stoch
>Assignee: Martin Grigorov
>Priority: Major
> Attachments: websocket-deser-onclose.zip
>
>
> We have a page with websocket connection (using WebSocketBehavior). When user
> navigates to another page, a websocket connection is closed and
> AbstractWebSocketProcessor.onClose method is called. This causes broadcasting
> a message to connected page:
> {code}
> broadcastMessage(new ClosedMessage(getApplication(), getSessionId(), key));
> {code}
> and leads to page deserialisation (from PageStore).
> I wonder how it can affect performance: almost every page navigation causes
> page deserialization (when it should occur only for back button or when some
> websocket message comes and application need to process it).
>
> Maybe this message should be send only when needed or maybe I should not care
> and current behaviour does not affect performance?
>
> I have attached a simple quick start:
> - click links to navigate between pages: “Nav 1” and “Home”,
> - after each click you can see “>> Closed message: …” on System.out (so
> closed message was sent),
> - AbstractWebSocketProcessor broadcast a ClosedMessage to a page, which
> causes its deserialization (you can debug IPageStore.getPage call).
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Commented] (WICKET-6692) Page deserialization on websocket close - possible performance issue
[
https://issues.apache.org/jira/browse/WICKET-6692?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16907218#comment-16907218
]
Martin Grigorov commented on WICKET-6692:
-
I've pushed a new "setting" in WebSocketSettings which can be used to decide
whether to call the onClose() method.
In Wicket 8.x it will call it by default to preserve the current behavior.
In Wicket 9.x we can change it to not call it if other developers/users say it
would be a good change.
> Page deserialization on websocket close - possible performance issue
>
>
> Key: WICKET-6692
> URL: https://issues.apache.org/jira/browse/WICKET-6692
> Project: Wicket
> Issue Type: Bug
> Components: wicket-native-websocket
>Affects Versions: 6.30.0, 8.5.0
>Reporter: Daniel Stoch
>Assignee: Martin Grigorov
>Priority: Major
> Attachments: websocket-deser-onclose.zip
>
>
> We have a page with websocket connection (using WebSocketBehavior). When user
> navigates to another page, a websocket connection is closed and
> AbstractWebSocketProcessor.onClose method is called. This causes broadcasting
> a message to connected page:
> {code}
> broadcastMessage(new ClosedMessage(getApplication(), getSessionId(), key));
> {code}
> and leads to page deserialisation (from PageStore).
> I wonder how it can affect performance: almost every page navigation causes
> page deserialization (when it should occur only for back button or when some
> websocket message comes and application need to process it).
>
> Maybe this message should be send only when needed or maybe I should not care
> and current behaviour does not affect performance?
>
> I have attached a simple quick start:
> - click links to navigate between pages: “Nav 1” and “Home”,
> - after each click you can see “>> Closed message: …” on System.out (so
> closed message was sent),
> - AbstractWebSocketProcessor broadcast a ClosedMessage to a page, which
> causes its deserialization (you can debug IPageStore.getPage call).
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Commented] (WICKET-6692) Page deserialization on websocket close - possible performance issue
[
https://issues.apache.org/jira/browse/WICKET-6692?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16907207#comment-16907207
]
Martin Grigorov commented on WICKET-6692:
-
This is how it behaved since day 1 of Wicket Native WebSocket integration.
I agree that most probably most of the applications do not care about this
event and can avoid the unnecessary deserialization.
I'll see whether this can be made configurable.
> Page deserialization on websocket close - possible performance issue
>
>
> Key: WICKET-6692
> URL: https://issues.apache.org/jira/browse/WICKET-6692
> Project: Wicket
> Issue Type: Bug
> Components: wicket-native-websocket
>Affects Versions: 6.30.0, 8.5.0
>Reporter: Daniel Stoch
>Assignee: Martin Grigorov
>Priority: Major
> Attachments: websocket-deser-onclose.zip
>
>
> We have a page with websocket connection (using WebSocketBehavior). When user
> navigates to another page, a websocket connection is closed and
> AbstractWebSocketProcessor.onClose method is called. This causes broadcasting
> a message to connected page:
> {code}
> broadcastMessage(new ClosedMessage(getApplication(), getSessionId(), key));
> {code}
> and leads to page deserialisation (from PageStore).
> I wonder how it can affect performance: almost every page navigation causes
> page deserialization (when it should occur only for back button or when some
> websocket message comes and application need to process it).
>
> Maybe this message should be send only when needed or maybe I should not care
> and current behaviour does not affect performance?
>
> I have attached a simple quick start:
> - click links to navigate between pages: “Nav 1” and “Home”,
> - after each click you can see “>> Closed message: …” on System.out (so
> closed message was sent),
> - AbstractWebSocketProcessor broadcast a ClosedMessage to a page, which
> causes its deserialization (you can debug IPageStore.getPage call).
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Updated] (WICKET-6684) Make autolabel functionality more flexible by introducing a locator interface that allows to specify the component the wicket:for refers to
[ https://issues.apache.org/jira/browse/WICKET-6684?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Grigorov updated WICKET-6684: Fix Version/s: 8.6.0 > Make autolabel functionality more flexible by introducing a locator interface > that allows to specify the component the wicket:for refers to > --- > > Key: WICKET-6684 > URL: https://issues.apache.org/jira/browse/WICKET-6684 > Project: Wicket > Issue Type: Improvement > Components: wicket-core >Affects Versions: 9.0.0-M2 >Reporter: Ernesto Reinaldo Barreiro >Assignee: Martin Grigorov >Priority: Minor > Fix For: 8.6.0, 9.0.0-M3 > > > Make autolabel functionality more flexible by introducing a locator interface > that allows to specify the component the wicket:for refers to. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Commented] (WICKET-6684) Make autolabel functionality more flexible by introducing a locator interface that allows to specify the component the wicket:for refers to
[ https://issues.apache.org/jira/browse/WICKET-6684?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16906305#comment-16906305 ] Martin Grigorov commented on WICKET-6684: - Downported it to branch wicket-8.x. > Make autolabel functionality more flexible by introducing a locator interface > that allows to specify the component the wicket:for refers to > --- > > Key: WICKET-6684 > URL: https://issues.apache.org/jira/browse/WICKET-6684 > Project: Wicket > Issue Type: Improvement > Components: wicket-core >Affects Versions: 9.0.0-M2 >Reporter: Ernesto Reinaldo Barreiro >Assignee: Martin Grigorov >Priority: Minor > Fix For: 9.0.0-M3 > > > Make autolabel functionality more flexible by introducing a locator interface > that allows to specify the component the wicket:for refers to. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Commented] (WICKET-6432) SignInPanel causes infinite redirect loop if session id is suppressed in URL
[
https://issues.apache.org/jira/browse/WICKET-6432?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16900766#comment-16900766
]
Martin Grigorov commented on WICKET-6432:
-
Let's close!
> SignInPanel causes infinite redirect loop if session id is suppressed in URL
>
>
> Key: WICKET-6432
> URL: https://issues.apache.org/jira/browse/WICKET-6432
> Project: Wicket
> Issue Type: Bug
> Components: wicket-auth-roles
>Affects Versions: 7.8.0
>Reporter: Simon Erhardt
>Assignee: Martin Grigorov
>Priority: Major
> Attachments: redirect-loop.zip
>
>
> The attached, very simple quickstart causes an infinite redirection loop. It
> consists of a _AuthenticatedPage_, which is annotated by
> _@AuthorizeInstantiation_, and a _LoginPage_, using a SingInPanel, which is
> set up as home page.
> The trouble begins if one opens the HTTP URL after signing in with HTTPS.
> It happens only if Jetty is forced to suppress the session id as URL
> parameter (see [Jetty 9.2.X
> documentation|http://www.eclipse.org/jetty/documentation/9.2.22.v20170531/session-management.html#setting-session-characteristics]):
> {code}
> WebAppContext bb = new WebAppContext();
> // The following line causes the trouble
>
> bb.setInitParameter("org.eclipse.jetty.servlet.SessionIdPathParameterName",
> "none");
> {code}
> Steps to reproduce:
> # Start the application in test/java/quickstart/Start
> # Open https://localhost:8443
> # Sign in using "user" and "password"
> # After redirected to the AuthenticatedPage, open http://localhost:8080
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Commented] (WICKET-6691) Support Meta annotations (e.g. for @AuthorizeInstantiation)
[
https://issues.apache.org/jira/browse/WICKET-6691?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16900761#comment-16900761
]
Martin Grigorov commented on WICKET-6691:
-
I like the proposal to support meta annotations for this use case!
> Support Meta annotations (e.g. for @AuthorizeInstantiation)
> ---
>
> Key: WICKET-6691
> URL: https://issues.apache.org/jira/browse/WICKET-6691
> Project: Wicket
> Issue Type: Improvement
>Reporter: Kees van Dieren
>Priority: Minor
>
> Would be nice to have Meta annotation support for certain Wicket annotations.
> For ex, we have some group of roles that are re-used accross several pages,
> like so:
> {code:java}
> @AuthorizeInstantiation({"roleA", "roleB", "roleC"})
> {code}
> Now we copy-paste this code across the pages that need them.
> Would be nice to be able to define an annotation for that, like so:
> {code:java}
> @Target(ElementType.TYPE)
> @Retention(RetentionPolicy.RUNTIME)
> @AuthorizeInstantiation({"roleA", "roleB", "roleC"})
> @Documented
> @Inherited
> public @interface SomeFeatureAuthorization {}
> {code}
> Then, on pages and components requiring authorization checks, just the
> annotation @SomeFeatureAuthorization has to be added, no longer repeating all
> the role names.
> Is such a thing already considered? It requires some changes in
> org.apache.wicket.authroles.authorization.strategies.role.annotations.AnnotationsRoleAuthorizationStrategy
> probably?
> We have other annotations as well in wicket, which also need to be considered
> if this is seen by community as useful addition.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Resolved] (WICKET-6689) ClientProperties.getTimeZone() has some issue when DST and UTC offsets are different
[
https://issues.apache.org/jira/browse/WICKET-6689?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Grigorov resolved WICKET-6689.
-
Resolution: Fixed
Fix Version/s: 9.0.0-M3
7.15.0
8.6.0
> ClientProperties.getTimeZone() has some issue when DST and UTC offsets are
> different
>
>
> Key: WICKET-6689
> URL: https://issues.apache.org/jira/browse/WICKET-6689
> Project: Wicket
> Issue Type: Bug
> Components: wicket
>Affects Versions: 9.0.0-M2
>Reporter: Mansour Rahimi
>Assignee: Martin Grigorov
>Priority: Major
> Fix For: 8.6.0, 7.15.0, 9.0.0-M3
>
>
> So ClientProperties.getTimeZone() got UTC offset 11 and DST offset 10
> (Australia Sydney), and it picked the wrong one (UTC +11). The issue is the
> way it's calculating the UTC-DST difference and looking up in the available
> time zone IDs.
> {code:java}
> if (dstTimeZone != null &&
> dstTimeZone.getRawOffset() !=
> timeZone.getRawOffset())
> {
> int dstSaving =
> dstTimeZone.getRawOffset() - timeZone.getRawOffset();
> String[] availableIDs =
> TimeZone.getAvailableIDs(timeZone.getRawOffset());
> for (String availableID :
> availableIDs)
> {
> TimeZone zone =
> TimeZone.getTimeZone(availableID);
> if
> (zone.getDSTSavings() == dstSaving)
> {
> // this is a
> best guess... still the start and end of the DST should
> // be needed to
> know to be completely correct, or better yet
> // not just the
> GMT offset but the TimeZone ID should be transfered
> // from the
> browser.
> timeZone = zone;
> break;
> }
> }
> }
> {code}
> If _dstTimeZone.getRawOffset() < timeZone.getRawOffset()_ then _dstSaving_ is
> negative and it would never find any zone in the _availableIDs_.
> I'm sending a PR for this.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Commented] (WICKET-6689) ClientProperties.getTimeZone() has some issue when DST and UTC offsets are different
[
https://issues.apache.org/jira/browse/WICKET-6689?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16890152#comment-16890152
]
Martin Grigorov commented on WICKET-6689:
-
Thank you!
> ClientProperties.getTimeZone() has some issue when DST and UTC offsets are
> different
>
>
> Key: WICKET-6689
> URL: https://issues.apache.org/jira/browse/WICKET-6689
> Project: Wicket
> Issue Type: Bug
> Components: wicket
>Affects Versions: 9.0.0-M2
>Reporter: Mansour Rahimi
>Assignee: Martin Grigorov
>Priority: Major
> Fix For: 8.6.0, 7.15.0, 9.0.0-M3
>
>
> So ClientProperties.getTimeZone() got UTC offset 11 and DST offset 10
> (Australia Sydney), and it picked the wrong one (UTC +11). The issue is the
> way it's calculating the UTC-DST difference and looking up in the available
> time zone IDs.
> {code:java}
> if (dstTimeZone != null &&
> dstTimeZone.getRawOffset() !=
> timeZone.getRawOffset())
> {
> int dstSaving =
> dstTimeZone.getRawOffset() - timeZone.getRawOffset();
> String[] availableIDs =
> TimeZone.getAvailableIDs(timeZone.getRawOffset());
> for (String availableID :
> availableIDs)
> {
> TimeZone zone =
> TimeZone.getTimeZone(availableID);
> if
> (zone.getDSTSavings() == dstSaving)
> {
> // this is a
> best guess... still the start and end of the DST should
> // be needed to
> know to be completely correct, or better yet
> // not just the
> GMT offset but the TimeZone ID should be transfered
> // from the
> browser.
> timeZone = zone;
> break;
> }
> }
> }
> {code}
> If _dstTimeZone.getRawOffset() < timeZone.getRawOffset()_ then _dstSaving_ is
> negative and it would never find any zone in the _availableIDs_.
> I'm sending a PR for this.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Assigned] (WICKET-6689) ClientProperties.getTimeZone() has some issue when DST and UTC offsets are different
[
https://issues.apache.org/jira/browse/WICKET-6689?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Grigorov reassigned WICKET-6689:
---
Assignee: Martin Grigorov
> ClientProperties.getTimeZone() has some issue when DST and UTC offsets are
> different
>
>
> Key: WICKET-6689
> URL: https://issues.apache.org/jira/browse/WICKET-6689
> Project: Wicket
> Issue Type: Bug
> Components: wicket
>Affects Versions: 9.0.0-M2
>Reporter: Mansour Rahimi
>Assignee: Martin Grigorov
>Priority: Major
>
> So ClientProperties.getTimeZone() got UTC offset 11 and DST offset 10
> (Australia Sydney), and it picked the wrong one (UTC +11). The issue is the
> way it's calculating the UTC-DST difference and looking up in the available
> time zone IDs.
> {code:java}
> if (dstTimeZone != null &&
> dstTimeZone.getRawOffset() !=
> timeZone.getRawOffset())
> {
> int dstSaving =
> dstTimeZone.getRawOffset() - timeZone.getRawOffset();
> String[] availableIDs =
> TimeZone.getAvailableIDs(timeZone.getRawOffset());
> for (String availableID :
> availableIDs)
> {
> TimeZone zone =
> TimeZone.getTimeZone(availableID);
> if
> (zone.getDSTSavings() == dstSaving)
> {
> // this is a
> best guess... still the start and end of the DST should
> // be needed to
> know to be completely correct, or better yet
> // not just the
> GMT offset but the TimeZone ID should be transfered
> // from the
> browser.
> timeZone = zone;
> break;
> }
> }
> }
> {code}
> If _dstTimeZone.getRawOffset() < timeZone.getRawOffset()_ then _dstSaving_ is
> negative and it would never find any zone in the _availableIDs_.
> I'm sending a PR for this.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Resolved] (WICKET-6690) NullPointerException in KeyInSessionSunJceCryptFactory.
[
https://issues.apache.org/jira/browse/WICKET-6690?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Grigorov resolved WICKET-6690.
-
Resolution: Fixed
Fix Version/s: 9.0.0-M3
7.15.0
8.6.0
Thanks for the report!
> NullPointerException in KeyInSessionSunJceCryptFactory.
> -
>
> Key: WICKET-6690
> URL: https://issues.apache.org/jira/browse/WICKET-6690
> Project: Wicket
> Issue Type: Bug
> Components: wicket-core
>Affects Versions: 8.5.0
> Environment: Windows 8.1
> Oracle JDK 1.8.0_191
>Reporter: David Rain
>Assignee: Martin Grigorov
>Priority: Major
> Fix For: 8.6.0, 7.15.0, 9.0.0-M3
>
>
> Call *Security.getProviders("Cipher." + cryptMethod).length == 0* causes
> *NullPointerException* when no suitable provider is found, because
> *getProviders* returns {color:#FF}*null*{color}.
> {code:java}
> 2019-07-22 07:22:37,604 - ERROR - [main,] -
> org.apache.wicket.protocol.http.WicketFilter - The initialization of an
> application with name 'wicket.cexi' has failed.
> java.lang.NullPointerException
> at
> org.apache.wicket.core.util.crypt.KeyInSessionSunJceCryptFactory.(KeyInSessionSunJceCryptFactory.java:67)
> {code}
> P.S.: I've noticed this when I tried init with
> *PBEwithSHA256and256bitAES-CBC-BC*
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Assigned] (WICKET-6690) NullPointerException in KeyInSessionSunJceCryptFactory.
[
https://issues.apache.org/jira/browse/WICKET-6690?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Grigorov reassigned WICKET-6690:
---
Assignee: Martin Grigorov
> NullPointerException in KeyInSessionSunJceCryptFactory.
> -
>
> Key: WICKET-6690
> URL: https://issues.apache.org/jira/browse/WICKET-6690
> Project: Wicket
> Issue Type: Bug
> Components: wicket-core
>Affects Versions: 8.5.0
> Environment: Windows 8.1
> Oracle JDK 1.8.0_191
>Reporter: David Rain
>Assignee: Martin Grigorov
>Priority: Major
>
> Call *Security.getProviders("Cipher." + cryptMethod).length == 0* causes
> *NullPointerException* when no suitable provider is found, because
> *getProviders* returns {color:#FF}*null*{color}.
> {code:java}
> 2019-07-22 07:22:37,604 - ERROR - [main,] -
> org.apache.wicket.protocol.http.WicketFilter - The initialization of an
> application with name 'wicket.cexi' has failed.
> java.lang.NullPointerException
> at
> org.apache.wicket.core.util.crypt.KeyInSessionSunJceCryptFactory.(KeyInSessionSunJceCryptFactory.java:67)
> {code}
> P.S.: I've noticed this when I tried init with
> *PBEwithSHA256and256bitAES-CBC-BC*
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Comment Edited] (WICKET-6688) Add alternative RPC response to substitute the append java script in ajax response
[
https://issues.apache.org/jira/browse/WICKET-6688?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16887390#comment-16887390
]
Martin Grigorov edited comment on WICKET-6688 at 7/17/19 8:07 PM:
--
I think there is no need to register the callbacks.
`target.appendJavaScript("doSomething()")` assumes that `doSomething` is a
global function, i.e. `window['doSomething']`. Even if it was namespaced, e.g.
`My.Namespace.doSomething` then Wicket can again look it up by:
`window['My'].['Namespace'].['doSomething']`. So the new implementation can
just look it up and apply/call it:
`window['My'].['Namespace'].['doSomething'].apply(context, param1, param2)`
was (Author: mgrigorov):
I think there is no need to register the callbacks.
`target.appendJavaScript("doSomething()")` assumes that `doSomething` is a
global function, i.e. `window['doSomething']`. Even if it was namespaced, e.g.
`My.Namespace.doSomething` then Wicket can again look it up by:
`window['My.Namespace.doSomething']`. So the new implementation can just look
it up and apply/call it: `window['My.Namespace.doSomething'].apply(context,
param1, param2)`
> Add alternative RPC response to substitute the append java script in ajax
> response
> --
>
> Key: WICKET-6688
> URL: https://issues.apache.org/jira/browse/WICKET-6688
> Project: Wicket
> Issue Type: Improvement
>Reporter: Andrew Kondratev
>Priority: Major
>
> Some kind of RPC could be added to eliminate 'unsafe-eval' in CSP headers.
> The idea is the following, instead of doing
> `target.appendJavaScript("doSomething()")` we could do something like this
> `target.appendRemoteCall("doSomething", "val1", "val2")`, the JS function
> could be rendered by the component/behavior as inline (which can be
> nonced).
> I implemented a proof of concept, using existing wicket ajax java
> infrastructure
> https://github.com/andruhon/WicketFetch/blob/master/src/main/java/org/apache/wicket/fetch/example/HomePage.java
> https://github.com/andruhon/WicketFetch/blob/master/src/main/java/org/apache/wicket/fetch/OnChangeFetchAjaxBehavior.java
> https://github.com/andruhon/WicketFetch/blob/master/src/main/java/org/apache/wicket/fetch/js/OnChangeFetchAjaxBehavior.js
> * OnChangeFetchAjaxBehavior.java renders a function into the header as
>