Re: Wicket inserting a div with inline styles on every form, vs. Content-Security-Policy
On Wed, Mar 29, 2017 at 5:48 PM, Martin Grigorov wrote: > On Wed, Mar 29, 2017 at 4:50 AM, Trejkaz wrote: >> So I guess I'd have to wait until Wicket these things to non-inline, >> and I see someone else already filed a ticket for it. > > Which ticket ? > About CSP or the inline CSS for the form field ? CSP in general. https://issues.apache.org/jira/browse/WICKET-5406 TX - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Wicket inserting a div with inline styles on every form, vs. Content-Security-Policy
On Wed, Mar 29, 2017 at 4:50 AM, Trejkaz wrote: > On Tue, Mar 28, 2017 at 5:17 PM, Martin Grigorov > wrote: > > Doesn't this break Ajax ? > > Wicket-Ajax uses eval() to execute target.appendJavaScript (and #prepend) > > and I have the feeling it won't work with this setup. > > You're right about that. We only have one page which uses any amount > of AJAX. It probably isn't terribly critical for it to work since it's > just tailing logs, but I just visited the page and indeed I get the > same problem there as well. > > So I guess I'd have to wait until Wicket these things to non-inline, > and I see someone else already filed a ticket for it. > Which ticket ? About CSP or the inline CSS for the form field ? > > TX > > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > >
Re: Wicket inserting a div with inline styles on every form, vs. Content-Security-Policy
On Tue, Mar 28, 2017 at 5:17 PM, Martin Grigorov wrote: > Doesn't this break Ajax ? > Wicket-Ajax uses eval() to execute target.appendJavaScript (and #prepend) > and I have the feeling it won't work with this setup. You're right about that. We only have one page which uses any amount of AJAX. It probably isn't terribly critical for it to work since it's just tailing logs, but I just visited the page and indeed I get the same problem there as well. So I guess I'd have to wait until Wicket these things to non-inline, and I see someone else already filed a ticket for it. TX - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: ComponentNotFoundException and Clustering failover
Hi,
Did you mention already which version of Wicket you use ?
There was an improvement related to reusing the page parameters when
constructing a new page instance in 7.0.0.
I have the feeling you are using 6.x. Am I correct ?
Martin Grigorov
Wicket Training and Consulting
https://twitter.com/mtgrigorov
On Tue, Mar 28, 2017 at 7:22 PM, Wayne W
wrote:
> Hello Martin,
>
> so I've been trying to still get to the bottom of this days later. So my
> understanding is getting better and it appears that the session itself is
> replicated fine. However I've tracked my issue down to the following:
>
> - If I have a page that has 2 links at the top. Link A is a Bookmarkable
> link back to the same page - it is also mounted thus: mountPage(
> "/cube/documents/${0}", CubeDocumentPage.class); It has a Long page param
> needed to construct the page ( i.e. /cube/documents/12345 ). The second
> link B is just a simple new Link("B") .
> - If both instances are up and running , lets say I am on instance A. I
> visit link A 3 times. I then kill instance A and I am balanced over to
> instance B. If I visit link B , the PageStoreManager cannot find the page
> that contains link B in the store and then tries to create a new instance
> of the page - the problem is then for some reason the page parameters are
> always null and the Long is never passed. Why is the page parameter always
> null here? Trying to debug it, is seems the IPageManager is got from the
> wicket Application instance and not the Session, and this IPageManager
> looks for a RequestAdaptor. Somewhere the page parameters are lost?.
>
> However I can get it to work this way:
> - start instance A, visit the page and say click link A 3 times.
> - Now start up instance B
> - Kill instance A
> - Click on the link B and this time the PageStoreManager finds the page and
> there the link B and everything works fine.
> It only works if I don't visit another page just after instance B starts
> up.
>
>
> I will do some more debugging tomorrow to try and understand this
> PageStoreManager/request adaptor bit more. But if you have any ideas I'd
> appreciate it.
> Thanks
>
>
>
> On Fri, Mar 24, 2017 at 12:48 PM, Martin Grigorov
> wrote:
>
> > Hi,
> >
> > On Fri, Mar 24, 2017 at 1:31 PM, Wayne W
> > wrote:
> >
> > > Thanks Martin,
> > >
> > > I have a theory what this is, perhaps you could confirm?
> > >
> > > What I observe is the following with the replication: If I visit page A
> > and
> > > then visit page B, then kill the instance I am on the session is
> > > successfully failed over to the other node. Now I'm still looking at
> > page B
> > > in the browser - if I hit back on the browser I get
> PageExpiredException.
> > > Is this the expected behaviour?
> > >
> >
> > No.
> > The expected behavior is to see the latest state of page A.
> >
> >
> > >
> > > If it IS the expected behaviour, then the reason I think that I have an
> > > issue with the page with the AbstractDefaultAjaxBehavior is because the
> > > code in the AbstractDefaultAjaxBehaviour.respond is adding components
> to
> > > the page which in turn marks the Session dirty which in turn replicates
> > the
> > > session. If only the last page/session commit is only replicated it
> could
> > > explain why I get a ComponentNotFound exception from the page as
> > > it overwriten by the update from the AbstractDefaultAjaxBehavior
> > >
> >
> > Any time the page is marked as dirty Wicket will store it in 1) the HTTP
> > session and 2) on the disk
> > 1) will notify the web server (e.g. Tomcat) that it has to replicate the
> > session because some attribute has been modified
> > At node2 Wicket will detect the replicated session in #readObject() and
> > store it on the disk.
> > From now on node2 will have the same history for that page as node1, i.e.
> > PageA and PageB.
> >
> > In addition:
> > Updates made in an Ajax requests do not add a new entry in the history
> > (storages) but overrides the previous entry for that page instance!
> > I.e. when PageA is rendered Wicket will assign a pageId for it, e.g. 5,
> and
> > store it in the disk.
> > Later when you make a change to PageA:5 in Ajax request then Wicket will
> > override the entry on the disk.
> > If you make a change in non-Ajax request then Wicket will assign a new
> > pageId, e.g. 6, and add a new entry in the history (disk), so you will
> have
> > two entries for this session.
> > Later when you open PageB then this will be pageId 7, etc.
> >
> >
> > >
> > > What do you think?
> > >
> > >
> > >
> > > On Fri, Mar 24, 2017 at 9:31 AM, Martin Grigorov >
> > > wrote:
> > >
> > > > Hi,
> > > >
> > > > Once the http session is replicated this method should be executed on
> > the
> > > > node that did not process the request
> > > > org.apache.wicket.page.PageStoreManager.SessionEntry#readObject().
> > > > Here Wicket will either store the page(s) on the disk or will
> schedule
> > > them
> > > > for storing.
> > > > There is no much usage of Loggers h
Re: ComponentNotFoundException and Clustering failover
Hello Martin,
so I've been trying to still get to the bottom of this days later. So my
understanding is getting better and it appears that the session itself is
replicated fine. However I've tracked my issue down to the following:
- If I have a page that has 2 links at the top. Link A is a Bookmarkable
link back to the same page - it is also mounted thus: mountPage(
"/cube/documents/${0}", CubeDocumentPage.class); It has a Long page param
needed to construct the page ( i.e. /cube/documents/12345 ). The second
link B is just a simple new Link("B") .
- If both instances are up and running , lets say I am on instance A. I
visit link A 3 times. I then kill instance A and I am balanced over to
instance B. If I visit link B , the PageStoreManager cannot find the page
that contains link B in the store and then tries to create a new instance
of the page - the problem is then for some reason the page parameters are
always null and the Long is never passed. Why is the page parameter always
null here? Trying to debug it, is seems the IPageManager is got from the
wicket Application instance and not the Session, and this IPageManager
looks for a RequestAdaptor. Somewhere the page parameters are lost?.
However I can get it to work this way:
- start instance A, visit the page and say click link A 3 times.
- Now start up instance B
- Kill instance A
- Click on the link B and this time the PageStoreManager finds the page and
there the link B and everything works fine.
It only works if I don't visit another page just after instance B starts up.
I will do some more debugging tomorrow to try and understand this
PageStoreManager/request adaptor bit more. But if you have any ideas I'd
appreciate it.
Thanks
On Fri, Mar 24, 2017 at 12:48 PM, Martin Grigorov
wrote:
> Hi,
>
> On Fri, Mar 24, 2017 at 1:31 PM, Wayne W
> wrote:
>
> > Thanks Martin,
> >
> > I have a theory what this is, perhaps you could confirm?
> >
> > What I observe is the following with the replication: If I visit page A
> and
> > then visit page B, then kill the instance I am on the session is
> > successfully failed over to the other node. Now I'm still looking at
> page B
> > in the browser - if I hit back on the browser I get PageExpiredException.
> > Is this the expected behaviour?
> >
>
> No.
> The expected behavior is to see the latest state of page A.
>
>
> >
> > If it IS the expected behaviour, then the reason I think that I have an
> > issue with the page with the AbstractDefaultAjaxBehavior is because the
> > code in the AbstractDefaultAjaxBehaviour.respond is adding components to
> > the page which in turn marks the Session dirty which in turn replicates
> the
> > session. If only the last page/session commit is only replicated it could
> > explain why I get a ComponentNotFound exception from the page as
> > it overwriten by the update from the AbstractDefaultAjaxBehavior
> >
>
> Any time the page is marked as dirty Wicket will store it in 1) the HTTP
> session and 2) on the disk
> 1) will notify the web server (e.g. Tomcat) that it has to replicate the
> session because some attribute has been modified
> At node2 Wicket will detect the replicated session in #readObject() and
> store it on the disk.
> From now on node2 will have the same history for that page as node1, i.e.
> PageA and PageB.
>
> In addition:
> Updates made in an Ajax requests do not add a new entry in the history
> (storages) but overrides the previous entry for that page instance!
> I.e. when PageA is rendered Wicket will assign a pageId for it, e.g. 5, and
> store it in the disk.
> Later when you make a change to PageA:5 in Ajax request then Wicket will
> override the entry on the disk.
> If you make a change in non-Ajax request then Wicket will assign a new
> pageId, e.g. 6, and add a new entry in the history (disk), so you will have
> two entries for this session.
> Later when you open PageB then this will be pageId 7, etc.
>
>
> >
> > What do you think?
> >
> >
> >
> > On Fri, Mar 24, 2017 at 9:31 AM, Martin Grigorov
> > wrote:
> >
> > > Hi,
> > >
> > > Once the http session is replicated this method should be executed on
> the
> > > node that did not process the request
> > > org.apache.wicket.page.PageStoreManager.SessionEntry#readObject().
> > > Here Wicket will either store the page(s) on the disk or will schedule
> > them
> > > for storing.
> > > There is no much usage of Loggers here so you will have to attach a
> > > debugger and see what happens.
> > >
> > > Martin Grigorov
> > > Wicket Training and Consulting
> > > https://twitter.com/mtgrigorov
> > >
> > > On Thu, Mar 23, 2017 at 6:11 PM, Wayne W
> > > wrote:
> > >
> > > > If I put the AbstractDefaultAjaxBehavior back in, it always fails.
> If I
> > > > remove the AbstractDefaultAjaxBehavior most of the time it works, but
> > > every
> > > > now and then it fails to replicate. Its really inconsistent.
> > > >
> > > > I have no idea how to get to the bottom of this. Any pointers or help
> > is
> > > > much
How save entity after clicking on submit button inside Form Wicket class.
Hi Everyone. When I try save entity inside simple WebPage like this
everything is ok:
import com.example.entities.Person;
import javax.ejb.EJB;
public class Register extends WebPage{
@EJB
NewSessionBeanLocal beanLocal;
public Register(){
NavomaticBorder navomaticBorder = new
NavomaticBorder("navigationBorder");
RegisterForm form = new RegisterForm("form");
navomaticBorder.add(form);
add(navomaticBorder);
// save entity to database for test
Person person = new Person();
person.setSurname("ABC");
person.setUsername("DEF");
beanLocal.addPerson(person); // IT IS OK
}
}
//
Html Form:
TODO supply a title
Username
Suername
//
but when i try do this inside Form, becouse I want save entity after click
on Subimt button (register Person):
import com.example.Repository.NewSessionBeanLocal;
import com.example.entities.Person;
import javax.ejb.EJB;
import org.apache.wicket.markup.html.form.Form;
import org.apache.wicket.markup.html.form.TextField;
import org.apache.wicket.model.CompoundPropertyModel;
public class RegisterForm extends Form{
@EJB
NewSessionBeanLocal beanLocal;
Person person = new Person();
public RegisterForm(String id) {
super(id);
CompoundPropertyModel model = new CompoundPropertyModel(person);
this.setModel(model);
this.add(new TextField("username"));
this.add(new TextField("surname"));
}
@Override
public void onSubmit() {
Person p = (Person)this.getModelObject();
System.out.println("TO: : : "+ p.getUsername()+ " "+
p.getSurname()); // shows right data
//Person p = new Person();
//p.setSurname("ABC");
//p.setUsername("DEF");
beanLocal.addPerson(p); // <-- PROBLEM IS HERE
}
}
I have error:
Unexpected RuntimeException:
Last cause: null
WicketMessage: Method onFormSubmitted of interface
org.apache.wicket.markup.html.form.IFormSubmitListener targeted at
[RegisterForm [Component id = form]] on component [RegisterForm [Component
id = form]] threw an exception
Root cause:
java.lang.NullPointerException
at
com.example.navigationBefore.RegisterForm.onSubmit(RegisterForm.java:34)
(...)
Something I'm doing wrong? I Should not save entity inside onSubmit() Form
method? Thank you for any advice.
--
View this message in context:
http://apache-wicket.1842946.n4.nabble.com/How-save-entity-after-clicking-on-submit-button-inside-Form-Wicket-class-tp4677474.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: AjaxButton submits despite form validation failure?
Awaiting confirmation from my co-worker that it worked, but we think we figured it out. He was adding the error message to the page level, above the form. Once he added the message to the form instead, the onSubmit does not fire. We saw the bit in the javadoc suggesting that we use AbstractFormValidator and he is going that way. The only odd part is that it seems like we've done this before and not had this problem. But we haven't gone looking, so can't be sure. -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/AjaxButton-submits-despite-form-validation-failure-tp4677463p4677472.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: Infinite Redirect Loop when using a Link
Hi, it is always toggling between and ?0: I am not using an HttpsMapper, however I am making an automated redirect on the Admin Interface from HTTP Port 9090 to HTTPS Port 8080 using a Jetty 'ConstraintSecurityHandler'. When not making this redirect, the problem does not happen. Mit freundlichen Grüßen / Best regards, René Hartwig Team Leader Software Development Mail: rene.hart...@cryptshare.com Phone: +49 761 38913 0 Fax:+49 761 38913 115 Web:www.cryptshare.com Befine Solutions AG - The Cryptshare company Werthmannstr. 15 79098 Freiburg Germany __ Are your attachments too large or confidential for common e-mail? Get to know Cryptshare! __ Interested in news and updates or you just like Cryptshare? Follow us! Newsletter | Linkedin l XING l Twitter l Youtube l Facebook | RSS l Google+ __ Register Court Freiburg HRB 6144, Board of Management: Mark Forrest, Dominik Lehr, Chairman of the Supervisor Board: Thilo Braun From: Martin Grigorov To: "users@wicket.apache.org" Date: 28.03.2017 13:57 Subject:Re: Infinite Redirect Loop when using a Link Hi, Put a breakpoint in WebPageRenderer#respond() or/and #redirectTo() and see what is the current url and what is the target url. Do you use HttpsMapper? If YES then play with org.apache.wicket.protocol.https.HttpsConfig#setPreferStateful(boolean) and see whether it helps. Martin Grigorov Wicket Training and Consulting https://twitter.com/mtgrigorov On Tue, Mar 28, 2017 at 1:50 PM, wrote: > Hi, > > I am using Wicket 7.6.0 with two Web Applications: > > Admin Interface on HTTPS Port 8080 using a SignInPanel > User Interface on HTTP Port 80 > > Now I have a very strange behavior - here is how I can reproduce it: > Delete all browser cookies > Visit the Admin Interface > Visit the User Interface (Using the same browser tab) > > --> An infinite redirect loop happens. The source of this problem is a > Link on the page returning 'false' for #getStatelessHint(). > > This is everything I have found out so far. Unfortunately I have not been > able to reproduce this behavior in a quickstart project. Do you have an > idea what might be causing this? > I found this issue related to a recent redirect-issue, but I do not think > that it has something to do with my problem, especially because it should > be fixed in this Wicket version already. > > > > Mit freundlichen Grüßen / Best regards, > René Hartwig > Team Leader Software Development > > Mail: rene.hart...@cryptshare.com > Phone: +49 761 38913 0 > Fax:+49 761 38913 115 > Web:www.cryptshare.com > Befine Solutions AG - The Cryptshare company > Werthmannstr. 15 > 79098 Freiburg > Germany > > __ > > Are your attachments too large or confidential for common e-mail? > Get to know Cryptshare! > > __ > > Interested in news and updates or you just like Cryptshare? Follow us! > Newsletter | Linkedin l XING l Twitter l Youtube l Facebook | > RSS l Google+ > > __ > Register Court Freiburg HRB 6144, Board of Management: Mark Forrest, > Dominik Lehr, Chairman of the Supervisor Board: Thilo Braun
Re: Infinite Redirect Loop when using a Link
Hi, Put a breakpoint in WebPageRenderer#respond() or/and #redirectTo() and see what is the current url and what is the target url. Do you use HttpsMapper? If YES then play with org.apache.wicket.protocol.https.HttpsConfig#setPreferStateful(boolean) and see whether it helps. Martin Grigorov Wicket Training and Consulting https://twitter.com/mtgrigorov On Tue, Mar 28, 2017 at 1:50 PM, wrote: > Hi, > > I am using Wicket 7.6.0 with two Web Applications: > > Admin Interface on HTTPS Port 8080 using a SignInPanel > User Interface on HTTP Port 80 > > Now I have a very strange behavior - here is how I can reproduce it: > Delete all browser cookies > Visit the Admin Interface > Visit the User Interface (Using the same browser tab) > > --> An infinite redirect loop happens. The source of this problem is a > Link on the page returning 'false' for #getStatelessHint(). > > This is everything I have found out so far. Unfortunately I have not been > able to reproduce this behavior in a quickstart project. Do you have an > idea what might be causing this? > I found this issue related to a recent redirect-issue, but I do not think > that it has something to do with my problem, especially because it should > be fixed in this Wicket version already. > > > > Mit freundlichen Grüßen / Best regards, > René Hartwig > Team Leader Software Development > > Mail: rene.hart...@cryptshare.com > Phone: +49 761 38913 0 > Fax:+49 761 38913 115 > Web:www.cryptshare.com > Befine Solutions AG - The Cryptshare company > Werthmannstr. 15 > 79098 Freiburg > Germany > > __ > > Are your attachments too large or confidential for common e-mail? > Get to know Cryptshare! > > __ > > Interested in news and updates or you just like Cryptshare? Follow us! > Newsletter | Linkedin l XING l Twitter l Youtube l Facebook | > RSS l Google+ > > __ > Register Court Freiburg HRB 6144, Board of Management: Mark Forrest, > Dominik Lehr, Chairman of the Supervisor Board: Thilo Braun
Infinite Redirect Loop when using a Link
Hi, I am using Wicket 7.6.0 with two Web Applications: Admin Interface on HTTPS Port 8080 using a SignInPanel User Interface on HTTP Port 80 Now I have a very strange behavior - here is how I can reproduce it: Delete all browser cookies Visit the Admin Interface Visit the User Interface (Using the same browser tab) --> An infinite redirect loop happens. The source of this problem is a Link on the page returning 'false' for #getStatelessHint(). This is everything I have found out so far. Unfortunately I have not been able to reproduce this behavior in a quickstart project. Do you have an idea what might be causing this? I found this issue related to a recent redirect-issue, but I do not think that it has something to do with my problem, especially because it should be fixed in this Wicket version already. Mit freundlichen Grüßen / Best regards, René Hartwig Team Leader Software Development Mail: rene.hart...@cryptshare.com Phone: +49 761 38913 0 Fax:+49 761 38913 115 Web:www.cryptshare.com Befine Solutions AG - The Cryptshare company Werthmannstr. 15 79098 Freiburg Germany __ Are your attachments too large or confidential for common e-mail? Get to know Cryptshare! __ Interested in news and updates or you just like Cryptshare? Follow us! Newsletter | Linkedin l XING l Twitter l Youtube l Facebook | RSS l Google+ __ Register Court Freiburg HRB 6144, Board of Management: Mark Forrest, Dominik Lehr, Chairman of the Supervisor Board: Thilo Braun
Re: AjaxButton submits despite form validation failure?
Hi, If you can reproduce this in a quickstart app with 6.26.0/7.6.0/8.0.0-M4 then please create a ticket in JIRA and attach it! Thank you! Martin Grigorov Wicket Training and Consulting https://twitter.com/mtgrigorov On Mon, Mar 27, 2017 at 7:28 PM, Entropy wrote: > A co-worker is having an issue that I am confused by. He has an AjaxButton > submitting a form that (among other things) hides on WebMarkupContainer and > shows another. But the form goes through a custom IFormValidator that > compares a few fields. > > When he violates the error, we can see the code invoke the error() method > on > the validator. Yet the onSubmit() fires anyway. He swears that it didn't > before he recently redid the page in accordance with requirements changes. > The main thrust of the changes is that it used to be that both > WebMarkupContainers were visible the entire time. > > Also, when the code get to onSubmit, he checks the message list, and it > shows as empty. He didn't turn defaultFormProcessing off, and I'm not even > sure what to look for at this point. I'm kind of hoping this is some > common > pitfall that someone will recognize instantly. > > -- > View this message in context: http://apache-wicket.1842946. > n4.nabble.com/AjaxButton-submits-despite-form- > validation-failure-tp4677463.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 > >
