Re: [ANNOUNCE] New Committer - Thomas Heigl

[Carl-Eric Menzel]

Welcome aboard, Thomas!

On Fri, 22 May 2020 21:08:09 +0200
Andrea Del Bene  wrote:

> The Apache Wicket team is happy to announce that Thomas Heigl has
> been voted in as a committer on Apache Wicket and also as a PMC
> member of the project! Thomas is an active member of the Wicket
> community since 2011 and lately has greatly contributed fixing bugs
> and providing ideas and pull requests to improve Wicket performance.
> 
> We're looking forward to working with Thomas in the near future, so 
> please join us in welcoming him to our project!
> 
> Andrea Del Bene
> Apache Wicket PMC chair.
> 

Re: Ajax Form submission and method mismatch

[Carl-Eric Menzel]

I've started working on it.

Incidentally, I just noticed that 6.x which I think is supposed to be 
targeting Java 6, can't actually be built with JDK6! The clirr maven 
plugin wants to run on at least Java 7. I'm going to work with Java 7 
for the time being.


On 02.02.2018 19:54, Sven Meier wrote:

Hi Carl-Eric,

WICKET-4107 was specifically about preventing GET request on stateless 
forms. Why not do something similar for Ajax behaviors?


Have fun

Sven


Am 01.02.2018 um 22:45 schrieb Carl-Eric Menzel:

Hi,

I've just encountered an interesting oddity. For a normal form 
submission, there is Form#onMethodMismatch where I can decide what 
should happen if somebody calls the form's URL with a GET request 
rather than the usual POST. At least in 6.x and 7.x this is called 
from onFormSubmitted() - but not from onFormSubmitted(submitter).


The result is that for forms that have an ajax button and thus a valid 
submitter, I can't stop somebody building a GET request and firing 
that against the button's URL. Theoretically I could override 
AjaxFormSubmitBehavior's onEvent method, but that doesn't work for 
ajax buttons, which build their own AjaxFormSubmitBehavior.


On one of my current projects the customer is quite security-minded 
and would like the application to block these GET requests. My 
question is: Is it intentional that only the regular onFormSubmitted() 
method checks this? If yes, I'd like to know the reasoning please. If 
not, I'm going to write a patch to fix this.


Or maybe I'm missing something and am going the wrong way entirely. In 
that case, let me know please.


Carl-Eric

Re: Ajax Form submission and method mismatch

[Carl-Eric Menzel]

GET requests can be triggered by someone opening a page with e.g. an
image URL pointing to that. In a small application, this URL can be
guessable.
But even if it weren't a security issue - I still would like to know why
there is this inconsistency between onFormSubmitted and
onFormSubmitted(submitter).

On Fri, Feb 2, 2018, at 15:39, Ernesto Reinaldo Barreiro wrote:
> Ok. But does that posses a real security issue? i.e not logged used
> triggering a click on "that" button that does not exists for them?
> 
> On Fri, Feb 2, 2018 at 3:36 PM, Carl-Eric Menzel
> <cmen...@wicketbuch.de>> wrote:
> 
>> You're not wrong, but I'd still like to be able to block GET. And the>> 
>> other question is **why** this check isn't done for forms with submit>> 
>> components (I haven't tried it, but I suspect using a regular button>> 
>> rather than an ajax button would run into the same issue).
>> 
>> On Fri, Feb 2, 2018, at 14:45, Ernesto Reinaldo Barreiro wrote:
>>> Hi,
>>> 
>>> Maybe I'm wrong but for AJAX only logged in user could get that
>>> REQUEST to> work because it is page relative.  Or am I completely
>>> wrong?>>> 
>>> On Thu, Feb 1, 2018 at 10:45 PM, Carl-Eric Menzel
>>> <cmen...@wicketbuch.de>> wrote:
>>> 
>>>> Hi,
>>>> 
>>>> I've just encountered an interesting oddity. For a normal form
>>>> submission,>> there is Form#onMethodMismatch where I can
>>>> decide what>> should
>>>> happen if>> somebody calls the form's URL with a GET request
>>>> rather than>>>> the usual>> POST. At least in 6.x and 7.x this is called 
>>>> from
>>>> onFormSubmitted() - but>> not from onFormSubmitted(submitter).
>>>> 
>>>> The result is that for forms that have an ajax button and thus
>>>> a valid>> submitter, I can't stop somebody building a GET
>>>> request and>>>> firing that>> against the button's URL. Theoretically I 
>>>> could
>>>> override>>>> AjaxFormSubmitBehavior's onEvent method, but that doesn't work
>>>> for ajax>> buttons, which build their own AjaxFormSubmitBehavior.
>>>> 
>>>> On one of my current projects the customer is quite security-
>>>> minded and>> would like the application to block these GET
>>>> requests. My>>>> question is: Is>> it intentional that only the regular
>> onFormSubmitted() method
>>>> checks this?>> If yes, I'd like to know the reasoning please.
>>>> If not,>> I'm going to
>>>> write a>> patch to fix this.
>>>> 
>>>> Or maybe I'm missing something and am going the wrong way
>>>> entirely. In>> that case, let me know please.
>>>> 
>>>> Carl-Eric
>>>> 
>>> 
>>> 
>>> 
>>> --
>>> Regards - Ernesto Reinaldo Barreiro
>> 
>> 
> 
> 
> --
> Regards - Ernesto Reinaldo Barreiro

Re: Ajax Form submission and method mismatch

[Carl-Eric Menzel]

You're not wrong, but I'd still like to be able to block GET. And the
other question is *why* this check isn't done for forms with submit
components (I haven't tried it, but I suspect using a regular button
rather than an ajax button would run into the same issue).

On Fri, Feb 2, 2018, at 14:45, Ernesto Reinaldo Barreiro wrote:
> Hi,
> 
> Maybe I'm wrong but for AJAX only logged in user could get that
> REQUEST to> work because it is page relative.  Or am I completely wrong?
> 
> On Thu, Feb 1, 2018 at 10:45 PM, Carl-Eric Menzel
> <cmen...@wicketbuch.de>> wrote:
> 
>> Hi,
>> 
>> I've just encountered an interesting oddity. For a normal form
>> submission,>> there is Form#onMethodMismatch where I can decide what should
>> happen if>> somebody calls the form's URL with a GET request rather than
>> the usual>> POST. At least in 6.x and 7.x this is called from
>> onFormSubmitted() - but>> not from onFormSubmitted(submitter).
>> 
>> The result is that for forms that have an ajax button and thus
>> a valid>> submitter, I can't stop somebody building a GET request and
>> firing that>> against the button's URL. Theoretically I could override
>> AjaxFormSubmitBehavior's onEvent method, but that doesn't work
>> for ajax>> buttons, which build their own AjaxFormSubmitBehavior.
>> 
>> On one of my current projects the customer is quite security-
>> minded and>> would like the application to block these GET requests. My
>> question is: Is>> it intentional that only the regular onFormSubmitted() 
>> method
>> checks this?>> If yes, I'd like to know the reasoning please. If not, I'm 
>> going to
>> write a>> patch to fix this.
>> 
>> Or maybe I'm missing something and am going the wrong way
>> entirely. In>> that case, let me know please.
>> 
>> Carl-Eric
>> 
> 
> 
> 
> --
> Regards - Ernesto Reinaldo Barreiro

Ajax Form submission and method mismatch

[Carl-Eric Menzel]

Hi,

I've just encountered an interesting oddity. For a normal form 
submission, there is Form#onMethodMismatch where I can decide what 
should happen if somebody calls the form's URL with a GET request rather 
than the usual POST. At least in 6.x and 7.x this is called from 
onFormSubmitted() - but not from onFormSubmitted(submitter).


The result is that for forms that have an ajax button and thus a valid 
submitter, I can't stop somebody building a GET request and firing that 
against the button's URL. Theoretically I could override 
AjaxFormSubmitBehavior's onEvent method, but that doesn't work for ajax 
buttons, which build their own AjaxFormSubmitBehavior.


On one of my current projects the customer is quite security-minded and 
would like the application to block these GET requests. My question is: 
Is it intentional that only the regular onFormSubmitted() method checks 
this? If yes, I'd like to know the reasoning please. If not, I'm going 
to write a patch to fix this.


Or maybe I'm missing something and am going the wrong way entirely. In 
that case, let me know please.


Carl-Eric

Re: [VOTE] Proposal to remove IDetachable from IModel hierarchy

[Carl-Eric Menzel]

[X] No, keep IModel detachable

I can see Pedro's point. A Model really is only something that can get
and set. But detaching is such an important part of the lifecycle of
many Wicket things (including Models) that I think it is an acceptable
tradeoff in clarity to have IModel extend IDetachable.

Carl-Eric

Re: Security Check of Mozilla / Wicket implementation

[Carl-Eric Menzel]

Hi Tobias,

thanks for collecting the headers, that saves me the effort :-) I know
it's easy to write, I was just suggesting we add something like this to
Wicket itself. I'll see whether I can come up with something simple and
flexible enough.

One question: Why onEndRequest?

Carl-Eric

On Sun, 28 Aug 2016 15:52:32 +0200
Tobias Soloschenko <tobiassolosche...@googlemail.com> wrote:

> Hi,
> 
> you are able to implement the security headers in a very easy way.
> See:
> 
> Mozilla tool to check web security: https://observatory.mozilla.org/
> 
> Demo wicket application (might be down or change after a while): 
> https://wicketsecurity-klopfdreh.rhcloud.com/
> 
> The test: 
> https://observatory.mozilla.org/analyze.html?host=wicketsecurity-klopfdreh.rhcloud.com
> 
> The implementation within your Wicket Application:
> 
>  @Override
>  protected void init()
>  {
>  super.init();
> 
>  getRequestCycleListeners().add(new
> AbstractRequestCycleListener(){ @Override
>  public void onEndRequest(RequestCycle cycle)
>  {
> ((WebResponse)cycle.getResponse()).setHeader("X-XSS-Protection", "1; 
> mode=block");
> ((WebResponse)cycle.getResponse()).setHeader("Strict-Transport-Security",
> "max-age=31536000; includeSubDomains; preload");
> ((WebResponse)cycle.getResponse()).setHeader("X-Content-Type-Options", 
> "nosniff");
> ((WebResponse)cycle.getResponse()).setHeader("X-Frame-Options",
> "DENY");
> ((WebResponse)cycle.getResponse()).setHeader("Content-Security-Policy",
> "default-src https:"); // Google "for Content-Security-Policy" to
> allow more domains }
>  });
>  }
> 
> The result: >> A- << (because of redirection settings of tomcat - I
> was not able to change them that fast)
> 
> To get A just enable a server redirect like mentioned here:
> 
> https://wiki.mozilla.org/Security/Guidelines/Web_Security#HTTP_Redirections
> 
> kind regards
> 
> Tobias
> 
> Am 28.08.16 um 10:28 schrieb Carl-Eric Menzel:
> > I think it would be a good idea to have something like this as an
> > option in Wicket. Something to turn on with a one-liner for the
> > application. There are a bunch of these headers that are useful,
> > plus I recently came across this:
> >
> > https://dev.to/ben/the-targetblank-vulnerability-by-example
> >
> > Should we perhaps also add something that adds the rel="noopener"
> > attribute to links with target="_blank"?
> >
> > I'm all for making these security things as easy as possible for the
> > developer.
> >
> > Carl-Eric
> >
> > On Sat, 27 Aug 2016 18:08:36 +0200
> > Martin Grigorov <mgrigo...@apache.org> wrote:
> >  
> >> Hi,
> >>
> >> We use Spring Security in all our applications.
> >> It adds these response headers for free.
> >>
> >> Any other Servlet Filter could do the same but I don't mind adding
> >> facilities in Wicket too.
> >>
> >> Btw one of the security experts from OWASP audited our applications
> >> in the last few weeks. Although he've found few problems here and
> >> there he said very nice words for Wicket!
> >>
> >> Martin Grigorov
> >> Wicket Training and Consulting
> >> https://twitter.com/mtgrigorov
> >>
> >> On Sat, Aug 27, 2016 at 6:01 PM, Tobias Soloschenko <  
> >> tobiassolosche...@googlemail.com> wrote:  
> >>  
> >>> Hi,
> >>>
> >>> Mozilla just made a tool public which allows to scan websites for
> >>> security risks. Maybe we can somehow add a default set of headers
> >>> to the page rendering of Wicket / apply other security relevant
> >>> implementations. Or we are able to make them at least optional:
> >>>
> >>> https://observatory.mozilla.org
> >>>
> >>> Example header:
> >>>
> >>> https://wiki.mozilla.org/Security/Guidelines/Web_Security#X-XSS-Protection
> >>>
> >>> What so you think about that idea?
> >>>
> >>> kind regards
> >>>
> >>> Tobias  
> 

Re: Security Check of Mozilla / Wicket implementation

[Carl-Eric Menzel]

I think it would be a good idea to have something like this as an
option in Wicket. Something to turn on with a one-liner for the
application. There are a bunch of these headers that are useful, plus I
recently came across this:

https://dev.to/ben/the-targetblank-vulnerability-by-example

Should we perhaps also add something that adds the rel="noopener"
attribute to links with target="_blank"?

I'm all for making these security things as easy as possible for the
developer.

Carl-Eric

On Sat, 27 Aug 2016 18:08:36 +0200
Martin Grigorov  wrote:

> Hi,
> 
> We use Spring Security in all our applications.
> It adds these response headers for free.
> 
> Any other Servlet Filter could do the same but I don't mind adding
> facilities in Wicket too.
> 
> Btw one of the security experts from OWASP audited our applications
> in the last few weeks. Although he've found few problems here and
> there he said very nice words for Wicket!
> 
> Martin Grigorov
> Wicket Training and Consulting
> https://twitter.com/mtgrigorov
> 
> On Sat, Aug 27, 2016 at 6:01 PM, Tobias Soloschenko <
> tobiassolosche...@googlemail.com> wrote:  
> 
> > Hi,
> >
> > Mozilla just made a tool public which allows to scan websites for
> > security risks. Maybe we can somehow add a default set of headers
> > to the page rendering of Wicket / apply other security relevant
> > implementations. Or we are able to make them at least optional:
> >
> > https://observatory.mozilla.org
> >
> > Example header:
> >
> > https://wiki.mozilla.org/Security/Guidelines/Web_Security#X-XSS-Protection
> >
> > What so you think about that idea?
> >
> > kind regards
> >
> > Tobias  

Re: Throw exception when setOutputMarkupId() on non-renderable component

[Carl-Eric Menzel]

+1 for that.

On Wed, 17 Aug 2016 14:59:03 +0700
Maxim Solodovnik  wrote:

> +1 for "throw an exception in DEV mode and log a WARN in PROD mode"
> 
> On Wed, Aug 17, 2016 at 2:56 PM, Martin Grigorov
>  wrote:
> 
> > Hi,
> >
> > What do you think on adding a new setting to ExceptionSettings that
> > says whether to log a WARN (default, as it does now) or to throw
> > exception when setOutputMarkupId/setOutputMarkupPlaceholderTag()
> > are used on component with #setRenderBodyOnly(true) or attached to
> >  ?
> >
> > I've had few occasions in the past few months where colleagues of
> > mine use  and later try to update it with Ajax.
> > The WARN log is buried amongst other logs (and developers usually
> > simply ignore WARNs) and I see it is hard for them to find out the
> > reason.
> >
> > If the setting proves to be useful then we can throw an exception
> > in DEV mode and log a WARN in PROD mode.
> >
> > https://github.com/apache/wicket/blob/bec52515f1bb2570f09140ba6f457c
> > 369f3a56b1/wicket-core/src/main/java/org/apache/wicket/
> > Component.java#L4019-L4035
> >
> >
> > Martin Grigorov
> > Wicket Training and Consulting
> > https://twitter.com/mtgrigorov
> >  
> 
> 
> 

Re: [discuss] Ability to not submitting a nested form

[Carl-Eric Menzel]

I added it, yes. I don't see any public references to it, and I can't
think of any uses for it either. Protected should be fine, as far as I
can tell. It was probably just an oversight to make it public in the
first place.

Carl-Eric

On Mon, 20 Apr 2015 15:53:23 +0300
Martin Grigorov mgrigo...@apache.org wrote:

 Hi,
 
 Looks OK to me.
 Please add unit (WicketTester) tests for it.
 
 Is there any reason why the #wantSubmitOnXyz() methods should be
 public and not protected?
 @Carl-Eric: I think you added #wantSubmitOnNestedFormSubmit(). Any
 problem if this is protected in 7.x?
 
 Martin Grigorov
 Wicket Training and Consulting
 https://twitter.com/mtgrigorov
 
 On Mon, Apr 20, 2015 at 3:44 PM, Sebastien seb...@gmail.com wrote:
 
  Hi devs,
 
  I have a recurrent use case where I need to prevent a nested form
  to be processed/validated/submitted. There is already some
  conditions that could achieve this (Form#isEnabledInHierarchy or
  #isVisibleInHierarchy), but it does not suit well in case of a
  component/widget which is shown/hidden using javascript only (like
  a Dialog for instance).
 
  Form has a #wantSubmitOnNestedFormSubmit method (default to false),
  which allows to submit a parent form when the nested form is
  posted. I was thinking about having a #wantSubmitOnParentFormSubmit
  (default to true) which does the opposite: preventing a nested form
  to be submitted.
 
  You can see the code proposal here:
 
  https://github.com/apache/wicket/commit/e29a7a08a59c9897dcaf3f5df1661cc03a04b644
 
  (btw, there is/was an error L1014/1025)
 
  What do you think?
 
  Best regards,
  Sebastien.
 

Re: Add onAddToPage() to Component

[Carl-Eric Menzel]

I've applied the changes you suggested, they seem to work nicely. Only
in the WICKET-5677 branch based on 6.x so far, I'll cherry-pick it to
master once we agree that we can integrate this.

Carl-Eric

On Thu, 21 Aug 2014 23:30:45 +0200
Carl-Eric Menzel cmen...@wicketbuch.de wrote:

 On Wed, 20 Aug 2014 15:26:45 +0300
 Martin Grigorov mgrigo...@apache.org wrote:
 
  Carl-Eric,
  
  could you please re-format the related classes in wicket-6.x branch
  so all noise like
  https://github.com/apache/wicket/compare/wicket-6.x...WICKET-5677#diff-bfa8bce2a5e14af19e42011a5e2d4c68L4380
  disappear ?
  Just open the same classes in wicket-6.x branch, format them,
  commit+push. Cherry-pick in master.
 
 Will do.
 
  I've added a comment on one of the commits in GitHub but so far I
  don't received a notification about it. Did you receive a
  notification about
  https://github.com/apache/wicket/commit/4703c1ae1af91fdcca44e34edbeeb8bbaeb63b6c#commitcomment-7456068
   ?
 
 I didn't get a notification. But I'll have a look.
 
 Carl-Eric

Re: Add onAddToPage() to Component

[Carl-Eric Menzel]

On Wed, 20 Aug 2014 15:26:45 +0300
Martin Grigorov mgrigo...@apache.org wrote:

 Carl-Eric,
 
 could you please re-format the related classes in wicket-6.x branch
 so all noise like
 https://github.com/apache/wicket/compare/wicket-6.x...WICKET-5677#diff-bfa8bce2a5e14af19e42011a5e2d4c68L4380
 disappear ?
 Just open the same classes in wicket-6.x branch, format them,
 commit+push. Cherry-pick in master.

Will do.

 I've added a comment on one of the commits in GitHub but so far I
 don't received a notification about it. Did you receive a
 notification about
 https://github.com/apache/wicket/commit/4703c1ae1af91fdcca44e34edbeeb8bbaeb63b6c#commitcomment-7456068
  ?

I didn't get a notification. But I'll have a look.

Carl-Eric

Re: Add onAddToPage() to Component

[Carl-Eric Menzel]

One difficulty I am finding:

If I do not simply fire onAdd for everything that gets added, then I
have to differentiate. What do I do if I re-add a container that is
already initialized, so its onReAdd should be called, but which has a
new child that is not initialized? Which event should happen in the
child, and how should it be propagated? Or the other way around, what
if I have a new container but an already initialized child? If the
container checks whether it is initialized before calling onReAdd on
its children, then the child would not receive the onReAdd.

This may look complicated, but I don't think it is a problem with the
idea of having an onAdd or onReAdd. It is rather a consequence of the
fact that Wicket allows components to be removed and added again in
different compositions. You can remove a subtree and then add a new
subtree that can have some of the old components.

In light of this, I am in favor of having a general onAdd that is
always called, and to more clearly document that onInitialize is
supposed to be a delayed constructor.

Carl-Eric

On Mon, 18 Aug 2014 13:00:26 +0200
Martin Grigorov mgrigo...@apache.org wrote:

 Wait for some more opinions.
 
 Martin Grigorov
 Wicket Training and Consulting
 https://twitter.com/mtgrigorov
 
 
 On Mon, Aug 18, 2014 at 12:38 PM, Carl-Eric Menzel
 cmen...@wicketbuch.de wrote:
 
  On Mon, 18 Aug 2014 11:49:51 +0200
  Martin Grigorov mgrigo...@apache.org wrote:
 
   Hi,
  
   I still find it confusing :-/
  
   1) with this we will have: the constructor, onInitialize() and
   onAddToPage() being called as component initializers. Way too much
   IMO. onInitialize() and onAddToPage() are exactly the same thing
   at this stage.
 
  At this stage, yes.
 
   2) onRemove() is not named onRemoveFromPage(). (I don't like the
   name onAddToPage())
 
  I'm not invested in the name, so that can be changed :-)
 
   Is it possible to redo it as onReAdd(), i.e. it will be called
   when the component is added to a parent and it is already
   initialized. Not sure but maybe all that is needed to do it is to
   remove the call to onAddToPage() in onInitialize(), and rename
   the method.
 
  Hm. That means that if I want to always react to being added, I'd
  have to do it in both onInitialize and onReAdd.
 
  However, I can see that it would potentially remove some confusion
  by more clearly defining the difference between the two.
 
  I'll give it a try and update the branch.
 
  Carl-Eric
 

Re: Add onAddToPage() to Component

[Carl-Eric Menzel]

On Mon, 18 Aug 2014 13:30:03 +0200
Martin Grigorov mgrigo...@apache.org wrote:

 I don't like the whole idea of re-adding component.
 Wizard is the only component in Wicket distro which fails
 the
 org.apache.wicket.core.util.objects.checker.OrphanComponentChecker. I
 think only the data (i.e. the models) should be kept around and the
 components should be re-created for every view of that data when this
 is needed. For me Wizard component is a bad practice.

I'm not convinced it is entirely bad, but I can see that it is at least
not optimal.

However, Wicket does not prohibit it and so I think we should make sure
it doesn't break in surprising ways.

That said, I don't want to conflate this with the problems of Wizard
too much, because I still think we should have a complement to
onRemove, whether we're looking at Wizard or not, just to be consistent.

I had a chat with Martin on IRC, he had a very good idea on how to
simplify onAddToPage to a more clearly defined onReAdd. Thank you
Martin!

I've pushed an update including tests to the WICKET-5677 branch. 

The much simpler implementation is now not much more than an else branch
in Component#fireInitialize. If the component is already initialized,
it doesn't call onInitialize, but rather onReAdd. This way we have a
clear distinction between the two callbacks and we don't need a second
tree traversal, since this just uses the one that is there for
onInitialize already.

Martin and everyone else, what do you think?

Carl-Eric

Re: [2/2] git commit: WICKET-5350 adjust components' wildcards

[Carl-Eric Menzel]

On Mon, 28 Jul 2014 12:12:21 +0300
Martin Grigorov mgrigo...@apache.org wrote:


  -   protected void onSelectionChanged(final Collection?
  extends T newSelection)
  +   protected void onSelectionChanged(final CollectionT
  newSelection)
 
 
 Should the application be allowed to add new items to newSelestion ?
 Is there a use case for this ?
 Or the idea is to make the API as open as possible and leave the
 application decide what to do ?

There is a use case: Upon the user selecting something, the application
may want to add something to the selection. Maybe one of the selected
values is dependent on another, and the second one can thus be
automatically selected.

Carl-Eric

Re: Passing Component or Class to IAuthorizationStrategy#isInstantiationAuthorized()

[Carl-Eric Menzel]

Thanks Igor for making my point much better than I did. I agree 100%.

Carl-Eric

On Fri, 20 Dec 2013 08:14:27 -0800
Igor Vaynberg igor.vaynb...@gmail.com wrote:

 this is a security check, so the whole idea is that it is ran before
 any of the user's code in the constructor which may have side-effects.
 eg a constructor marking a record as ready to be deleted because a
 delete panel was instantiated. the class itself should be enough. even
 if you get an instance you cant use anything in it because its
 partially constructed. the question is if we do pass an instance how
 many users will bother reading javadoc? and out of those how many
 really understand how objects are constructed? i think we should close
 the issue as wont-fix, reading it It would be easier to decide if
 instantiation is authorized if one could access some properties of the
 component being constructed. which is exactly what you cannot/must
 not do because the object is only partially initialized, thus proving
 my point above.
 
 the ComponentInstantiationListener is a very special case where we
 make an exception. the entire point of this interface is to work with
 a partially constructed object and most users will never implement
 their own as opposed to the authorization strategy...
 
 -igor
 
 
 On Fri, Dec 20, 2013 at 12:53 AM, Martin Grigorov
 mgrigo...@apache.org wrote:
  Hi,
 
  The reporter of https://issues.apache.org/jira/browse/WICKET-5454
  asked to pass the Component instance
  to  IAuthorizationStrategy#isInstantiationAuthorized() instead of
  just its class.
  I have no idea why the API has been designed this way but Carl-Eric
  gave a good explanation - the component is not yet fully
  constructed.
 
  The thing that bothers me is why it is OK to use the instance in my
  custom IComponentInstantiationListener and it is not OK to do the
  same in IAuthorizationStrategy#isInstantiationAuthorized() ?
  If there is a javadoc explaining the possible problem (as for
  IComponentInstantiationListener#onInstantiation()) then it is OK.
 
  Even more - at
  https://github.com/apache/wicket/blob/master/wicket-core/src/main/java/org/apache/wicket/Application.java#L276you
  can see that right ater rejecting the *Class* we pass the *instance*
  to
  the UnauthorizedComponentInstantiationListener!
 
 
  Martin Grigorov
  Wicket Training and Consulting

Re: Broadcast.EXACT with Behavior

[Carl-Eric Menzel]

+1

On Wed, 4 Sep 2013 10:30:42 -0700
Igor Vaynberg igor.vaynb...@gmail.com wrote:

 yep
 
 -igor
 
 On Wed, Sep 4, 2013 at 9:40 AM, Martin Grigorov
 mgrigo...@apache.org wrote:
  that is: just notify the component and all its behaviors?
 
  On Sep 4, 2013 6:53 PM, Igor Vaynberg igor.vaynb...@gmail.com
  wrote:
 
  i think it makes sense to be able to target a component as the most
  fine grained receiver and letting all behaviors check in and see if
  they want to respond.
 
  -igor
 
  On Wed, Sep 4, 2013 at 3:13 AM, Martin Grigorov
  mgrigo...@apache.org
  wrote:
   Hi,
  
   https://issues.apache.org/jira/browse/WICKET-5339 requests to be
   able to broadcast events to component's behaviors when the type
   is EXACT.
  
   I've attached a patch that allows to send event to a specific
   behavior:
  
 send(someBehavior, Broadcast.EXACT, event)
  
  
   The reporter of the ticket asks for a bit different behavior :
  
 send(someComponent, Broadcast.EXACT, event)
  
   to send the event to the provided component and all its
   behaviors.
  
   Do you agree with his request or we will need a new Broadcast
   type for
  this
   ?

Re: RFC-0001: Deprecating PageParameters for Wicket 7 (was Re: [4/4] git commit: WICKET-4997)

[Carl-Eric Menzel]

I haven't had time to read the proposal in its entirety yet, so I just
skimmed it. My first impression is pretty good. There are of course
some things still missing, such as programmatically changing page
parameters to update the displayed URL in the browser, and centralized
mounting.

I'm not sure this fixes a major problem, but it would certainly be nice
to not have to do manual string conversions anymore as we are currently
doing with PageParameters.

On the other hand, I'm not a big fan of sprinkling annotations
everywhere. It feels like that usually only fixes the easy cases - of
course, the easy cases are fixed very nicely that way.

I'm struggling to come up with a scenario that wouldn't be covered by
this, but for now I just have this nagging feeling that there should
still be a programmatic way to extract parameters, not just the
annotation based stuff.

I'll be back with more comments after the weekend, I hope.



On Thu, 22 Aug 2013 17:55:45 +0200
Martijn Dashorst martijn.dasho...@gmail.com wrote:

 In the previous thread where I spin this message from it was
 mentioned by Emond that he and I were discussing request parameters
 and how Wicket handles them.
 
 It occurred to me that the PageParameters construct is still with us
 from 2004 and that it hasn't changed much since. In fact I'd posit
 that PageParameters are confusing and archaic when compared to more
 modern web technologies, e.g. jax-rs.
 
 So we started to write an RFC for Wicket, trying to document exactly
 what we want to change and how it should behave. It is quite a work
 in progress, but I like the first baby steps.
 
 There is not a good platform to host the rfc text (I loathe the
 confluence editor and markup), so I put it in a gist at github, as a
 place to read it, comment on it, and suggest improvements.
 
 You can find the first–incomplete as in not written yet–cut of Wicket
 RFC-0001 here [1]
 
 It is my intention to see if we can get consensus on this subject, and
 start implementing it in wicket 7.
 
 If we were to implement this, it would mean at least the following API
 breaks:
 
 1. Remove Page#PageParameters constructor
 2. Remove PageParameters storage from Page
 3. Remove Page#getPageParameters()
 4. Remove PageParameters
 
 In turn we would get type safe parameters for pages, a clear semantic
 how request parameters relate to the life cycle of pages and
 components and annotation based declaration of mount paths for pages.
 
 I at least like the provided examples, though we haven't touched the
 difficult subjects yet, such as URL generation, keeping them sync'd
 when doing partial page refreshes (read: AJAX), etc.
 
 Martijn
 
 [1] https://gist.github.com/dashorst/6308833#file-wicket-rfc-0001-txt
 
 PS. I like the RFC format quite a bit as it allows me to explore the
 intent and consequences before implementing a change. The examples
 make it more concrete to my taste and if this one is successful (i.e.
 either we accept the RFC or we don't accept the RFC based on the
 contents) I'd like to see more of them.
 
 PS2. anyone with an interest is invited to help out with the details
 and the grander picture. You don't need commit bits to help out with
 this subject.

Re: [VOTE] Accept the Wicket Free Guide as a part of Apache Wicket

[Carl-Eric Menzel]

I think it would help to have a neutral (i.e. Apache) host for the
documentation if you want to have more contributors. I'm pretty sure
many would be reluctant to contribute to something that is then
presented as From this company that I don't actually work for.

To my untrained eye the legal situation seems to be alright. ComSysto
are well within their rights to host this documentation, it's
originally theirs after all. And don't get me wrong, it is definitely a
very good piece of work. Also, we could use Andrea's contribution to
the ASF and host that here.

But I think it would be very confusing for users if we had a second,
diverging version of the documentation at Apache.

I think it should either become the official documentation and live at
Apache, *or* it should be at ComSysto. Either way is fine, but not both.

Therefore, I'd like to change my vote to -0.5 until this is cleared up. 

Carl-Eric

On Mon, 19 Aug 2013 23:10:48 +0200
Andrea Del Bene an.delb...@gmail.com wrote:

 I understand your concerns. The original plan was to bring it to
 GitHub to easily collect contributions also from other users, hence
 its repository should became public. However, this project is quite
 recent and is a work in progress and I must ask my colleagues and my
 boss for more details about it.
 That said, I still believe that the natural evolution of the guide is
 to be part of the project to become that free documentation that was 
 missing. In addition, I hope that under the Apache umbrella, it will
 be easier to maintain it and find other contributors.
 
 
  Andrea,
 
  Does this mean that there will be two versions of the guide ? One
  at Apache that uses the attachment in
  WICKET-5321https://issues.apache.org/jira/browse/WICKET-5321 and
  another maintained by ComSysto ?
  If YES then which one you will work on ? :-)
 
  I understand why Martijn wants the guide to be in ASF but my
  concerns are that:
  - there will be two versions of the guide and this will confuse the
  users,
  - and the ASF one will be behind the commercially supported one
 
 
  On Mon, Aug 19, 2013 at 10:40 PM, Andrea Del Bene
  an.delb...@gmail.comwrote:
 
  Hi,
 
  there's no problem from a legal point of view. My company started
  to convert the guide to HTML the same days Martijn asked me to
  join Wicket team and we (at comSysto) are planning to enrich it
  with some use-cases from our customers. That said, as long as you
  use my original guide, you don't have to be afraid of anything as
  it was published under Creative Commons by-nc-sa
  (http://creativecommons.org/**licenses/by-nc-sa/2.0/http://creativecommons.org/licenses/by-nc-sa/2.0/)
  and you are free to modify and redistribute it. In addition,
  there's an explicit agreement between me and ASF that grants to
  this last one any right on this document for future
  usages/developments.
 
  Hope to have been clear.
 
  Andrea.
 
On Mon, Aug 19, 2013 at 7:55 AM, Martin Grigorov
  mgrigo...@apache.org
  wrote:
-0
  The guide is already published in HTML format [1] by ComSysto -
  Andrea's new employer.
  [...] whether everything is still legal.
 
I'll let Andrea comment on the ComSysto part.
  As far as legal is concerned: if Andrea still intends to grant us
  the guide, it is legal and within the ASF guidelines. AFAIK the
  document was written by Andrea in his time and by him, and it is
  his right to distribute
  and license as he sees fit.
 
  Martijn
 
 
 

Re: Michael Mosmann is a committer and PMC member!

[Carl-Eric Menzel]

On Mon, 1 Jul 2013 11:51:15 +0200
Martijn Dashorst martijn.dasho...@gmail.com wrote:

 Please welcome Michael Mosmann as our newest addition to the Wicket
 team!
 
 Michael has been a long time contributor to Wicket, and even wrote a
 book on the subject. His day to day work keeps him busy with Wicket so
 we are very happy that Michael wanted to join our band of merry men!

Welcome to the team!

Carl-Eric

Re: [ANN] wicketstuff-lazymodel

[Carl-Eric Menzel]

On Tue, 19 Feb 2013 09:17:55 +0100
Sven Meier s...@meiers.net wrote:

 I don't see how 'B' can have method #bind(IModel)
 
 Correct, I fixed the example to declare B as LazyModelB.
 
 I also saw performance tests which verify that LazyModel is at least
 twice faster than PropertyModel.
 
 Not quite:
 In my idealized test-case it is at most 2 times *slower* than
 PropertyModel. This holds when each LazyModel is used (i.e.
 getObject() called) at least ten times, e.g. in an Ajax heavy
 application where you stay on a single page for a longer time. If
 each LazyModel is used once only (e.g. on a stateless page) it might
 get up to 5 times slower than PropertyModel. That proxying comes at a
 high price, there's no way around it :/. PropertyModel is still the
 king of performance. Or you have to switch to a preprocessor solution
 like bindgen-wicket.

Or you can do it like SafeModel does: Instead of reflecting all the
way, construct the property expression once and simply return an
AbstractPropertyModel. That would also allow some other tricks (we rely
on the property expression being available in my main project).

Carl-Eric

Re: Make attribute modifier a temporary behavior?

[Carl-Eric Menzel]

On Thu, 27 Sep 2012 11:28:17 +0200
Martijn Dashorst martijn.dasho...@gmail.com wrote:

 I encounter the following code quite often in our company's codebase:
 
 @Override
 protected void onBeforeRender() {
 add(AttributeModifier.replace(class, someCondition ? someValue
 : someOtherValue));
 }
 
 This is of course a (often a minor) memory leak: each time the
 component gets rendered, a new attribute modifier is added to the list
 of behaviors, each overwriting the class attribute. The correct code
 would of course be:

This is simply a bug, in my opinion, and there's an easy fix that you
have already shown.

Changing AttributeModifier to become temporary would be a silent
behavior change that will very likely bite many more users than those
who have code with the shown bug. I haven't seen this in our codebase
at all, for example. But I'd certainly scratching my head if these
modifiers suddenly were to disappear after the first request.

So, my opinion is: -1. Better to improve documentation for this.

Carl-Eric

Re: Eclipse settings

[Carl-Eric Menzel]

+1

Sounds nifty. I'll have to steal that for my projects once I see how it
works :-)

Carl-Eric

On Tue, 25 Sep 2012 15:37:27 +0200
Martijn Dashorst martijn.dasho...@gmail.com wrote:

 I'm not sure who is using eclipse or some other IDE, but currently I
 don't have the proper formatting settings in my local checkout of
 Wicket. AFAIR we used to have the formatting rules specified.
 
 I don't know whether m2eclipse supports updating the eclipse
 formatting settings from a jar file, but fortunately the
 maven-eclipse-plugin does (and isn't a resource hog for your average
 day Java coding).
 
 At topicus we have a jar file (topicus-eclipse-settings-0.1.jar) that
 contains all settings for eclipse that are relevant for working in a
 team: centralized formatting rules, etc. We deploy this through our
 maven repository and let the maven-eclipse-plugin update these
 workspace settings whenever you run mvn eclipse:eclipse
 
 I consider this a really good way of using and sharing settings, and
 I'd like to propose to do the same for Wicket.
 
 For this to happen, I would like to create a project in our subversion
 repository (wicket-common/wicket-eclipse-settings/) that contains our
 formatting settings, get the settings from one of you guys, release it
 to maven central, and let the maven-eclipse-plugin depend on it such
 that with a new mvn eclipse:eclipse the project will have the correct
 settings.
 
 The benefit is that the eclipse settings are no longer part of the
 official wicket checkout, and are only applied when someone is using
 Eclipse—hence no longer 'polluting' the tree.
 
 Who is with me?
 
 Martijn
 

Re: Eclipse settings

[Carl-Eric Menzel]

100 is maybe a bit too small, but I don't think we should go higher
than 120. I like having relatively short lines (same reason why
newspapers print in columns, easier for the eyes), and also that way I
can have several other views open next to the editor.

Carl-Eric

*let the formatting flame wars begin!! :-D*

On Tue, 25 Sep 2012 16:54:25 +0300
Martin Grigorov mgrigo...@apache.org wrote:

 I don't use the Eclipse .settings for a while.
 I've tried to setup a config similar for IDEA but there may be small
 differences with yours.
 
 I think 100 chars limit is too low these days. I work on a laptop and
 still find that I have plenty of free space on the right in the
 editor.
 
 On Tue, Sep 25, 2012 at 4:47 PM, Martijn Dashorst
 martijn.dasho...@gmail.com wrote:
  It appears that I *do* have the settings in my workspace in the
  checkout, but that somehow not everybody has them (completely)
  applied.
 
  For example a file that I saved was wrapped because it extended the
  100 character limit that is in eclipse settings, but the original
  line was just one.
 
  Martijn
 
  On Tue, Sep 25, 2012 at 3:37 PM, Martijn Dashorst
  martijn.dasho...@gmail.com wrote:
  I'm not sure who is using eclipse or some other IDE, but currently
  I don't have the proper formatting settings in my local checkout of
  Wicket. AFAIR we used to have the formatting rules specified.
 
  I don't know whether m2eclipse supports updating the eclipse
  formatting settings from a jar file, but fortunately the
  maven-eclipse-plugin does (and isn't a resource hog for your
  average day Java coding).
 
  At topicus we have a jar file (topicus-eclipse-settings-0.1.jar)
  that contains all settings for eclipse that are relevant for
  working in a team: centralized formatting rules, etc. We deploy
  this through our maven repository and let the maven-eclipse-plugin
  update these workspace settings whenever you run mvn
  eclipse:eclipse
 
  I consider this a really good way of using and sharing settings,
  and I'd like to propose to do the same for Wicket.
 
  For this to happen, I would like to create a project in our
  subversion repository (wicket-common/wicket-eclipse-settings/)
  that contains our formatting settings, get the settings from one
  of you guys, release it to maven central, and let the
  maven-eclipse-plugin depend on it such that with a new mvn
  eclipse:eclipse the project will have the correct settings.
 
  The benefit is that the eclipse settings are no longer part of the
  official wicket checkout, and are only applied when someone is
  using Eclipse—hence no longer 'polluting' the tree.
 
  Who is with me?
 
  Martijn
 
  --
  Become a Wicket expert, learn from the best:
  http://wicketinaction.com
 
 
 
  --
  Become a Wicket expert, learn from the best:
  http://wicketinaction.com
 
 
 

Re: Releasing in a semver world (= 6.x)

[Carl-Eric Menzel]

+1 for B as well.

We also need to think about how we will actually *do* the branching,
and especially the merging. So far what I've seen were three totally
separate branches with only cherry-picking going in between them. In my
opinion, that's not a very good way to use git, which is far more
powerful than that.

I don't have time right now, but I hope to soon write a short article
on how we do it in my current project, and offer that up for comments.

Carl-Eric

On Mon, 10 Sep 2012 09:05:20 -0700
Igor Vaynberg igor.vaynb...@gmail.com wrote:

 +1 for option B.
 
 -igor
 
 On Mon, Sep 10, 2012 at 5:31 AM, Martijn Dashorst
 martijn.dasho...@gmail.com wrote:
  We now live in a semver world and we need to agree on some basics:
  how we are going to maintain and release our software.
 
  From what I have heard from several folks in jira, mail, IRC and
  direct communication is that we have basically 2 camps:
 
  A. develop and release bug fixes until we we start developing for
  minor/major releases 6.1 (and 7.0).
 
  versus
 
  B. develop and release minor releases, only backporting critical
  bugs and releasing bug fix releases in case of critical bugs
 
  As we are following semver, both are valid strategies.
 
  Option A would require separate branches for 6.0.z, and 6.y
  Option B would require only branches 6.y.z when critical bugs are
  found—which should be rare.
 
  Option A would probably result in some releases like:
   - 6.0.1, 6.0.2, 6.0.3, 6.1.0, 6.0.4, 6.1.1, 6.1.2, 6.1.3, 6.0.5,
  6.2.0, 6.1.4
 
  Whereas option B should result in releases like:
   - 6.1.0, 6.2.0, 6.3.0, 6.3.1, 6.4.0, 6.5.0, 6.4.1
 
  What do you think?
 
  Martijn

[CVE-2012-3373] Apache Wicket XSS vulnerability via manipulated URL parameter

[Carl-Eric Menzel]

Severity: Important

Vendor:
The Apache Software Foundation

Versions Affected:
Apache Wicket 1.4.x and 1.5.x

Description:
https://wicket.apache.org/2012/09/06/cve-2012-3373.html
It is possible to inject JavaScript statements into an ajax link by
adding an encoded null byte to a URL pointing to a Wicket app. This
could be done by sending a legitimate user a manipulated URL and
tricking the user into clicking on it.

This vulnerability is fixed in
- Apache Wicket 1.4.21
  https://wicket.apache.org/2012/09/05/wicket-1.4.21-released.html
- Apache Wicket 1.5.8
  https://wicket.apache.org/2012/08/24/wicket-1.5.8-released.html

Apache Wicket 6.0.0 is not affected.

Credit:
This issue was reported by Thomas Heigl.

Apache Wicket Team

Apache Wicket 1.4.21 is released

[Carl-Eric Menzel]

This is 21st release of the Wicket 1.4.x series. This is also the last
release of the 1.4.x series, rounding up the remaining bugfixes. No
further releases will happen in this branch.

Git tag:
release/wicket-1.4.21

Changelog:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310561version=12320171

Maven:
dependency
groupIdorg.apache.wicket/groupId
artifactIdwicket/artifactId
version1.4.21/version
/dependency

Download the full distribution (including source):
http://www.apache.org/dyn/closer.cgi/wicket/1.4.21

The Wicke

[VOTE] Release Wicket 1.4.21

[Carl-Eric Menzel]

It's time to mop up the last remaining changes in 1.4.x so we can
finally close that branch and concentrate on 1.5 and 6.0.

Please check the following source release and then vote:
 - branch build/wicket-1.4.21
 - source tarball
https://people.apache.org/~cmenzel/wicket-1.4.21/apache-wicket-1.4.21-git.tgz

Signature and hashes available there too.

[ ] +1 release Apache Wicket 1.4.21
[ ] -1 don't release Apache Wicket 1.4.21

This vote lasts until Monday, September 3rd, 16:00CET. (longer time
because today is almost over and the weekend is coming up soon again).

Carl-Eric

Re: [VOTE] Release Wicket 6.0.0 final

[Carl-Eric Menzel]

+1

I don't have anything major with 6.0 yet so I gave my training
application a quickdirty port to 6.0 from 1.5. Everything seems to
work fine after a few adjustments.

On Mon, 27 Aug 2012 11:27:10 +0200
Emond Papegaaij emond.papega...@topicus.nl wrote:

 +1
 
 Checked:
   - tag (with signing)
   - zip contents and build
   - selenium tests for a large application
 
 Emond
 
 On Thursday 23 August 2012 23:13:28 Martijn Dashorst wrote:
  No fuzz, no separate RC releases. This is the real deal.
  
  Please vote for releasing the following source artifacts after
  checking them thoroughly for any misgivings:
  
   - tag: wicket-6.0.0
   - release branch: builds/wicket-6.0.0
   - artifacts:
 - apache-wicket-6.0.0.tar.gz
 - apache-wicket-6.0.0.zip
  
  They can be found at my p.a.o place:
  http://people.apache.org/~dashorst/wicket-6.0.0
  
  I have uploaded the signatures and hashes as well. I also signed the
  release tag (wicket-6.0.0). Probably you can sign the tag as well if
  you find the release to be OK (I haven't done such a thing myself,
  so you need to look it up somewhere—Emond?)
  
  [ ] +1 release Apache Wicket 6.0.0
  [ ] -1 don't release Apache Wicket 6.0.0
  
  This vote lasts for 4 days, due to the weekend coming up. I'll tally
  tuesday morning CET.
  
  Martijn

Re: [Vote] Release Apache Wicket 1.5.8

[Carl-Eric Menzel]

+1

Built and tested our project's main application, seems to work fine.

Carl-Eric

Re: [Vote] 6.0.0 -beta3 or RC1 ?

[Carl-Eric Menzel]

+1 for beta3 in a few days.

I'd like to get my cleanup of ResourceStreamLocator in before we freeze
the API. I'm not sure yet whether I'll have a breaking change (possibly
changing getResourceFinder() in Application to return a list rather
than just a single one).

Carl-Eric

On Mon, 25 Jun 2012 13:30:36 -0700
Igor Vaynberg igor.vaynb...@gmail.com wrote:

 +1 for RC1
 
 -igor
 
 On Mon, Jun 25, 2012 at 1:17 PM, Martin Grigorov
 mgrigo...@apache.org wrote:
  Hi,
 
  It is almost one month since 6.0.0-beta2 and there are 43 resolved
  issues. We have to decide whether the next will be beta3 or RC1.
 
  In the last month there were some API changes related to the
  generics in the SortState in wicket-extensions,
  IResourceStreamWriter#write(Response) is reverted back to
  #write(OutputStream) (contributed by Jesse Long) and form
  submitter's #onSubmit() splitted to #onSubmitBeforeForm() and
  #onSubmitAfterForm() (Carl-Eric).
  The changes are not big but I want you to take them into account
  before deciding whether it is time for RC1.
 
  There is also a ticket about removing completely
  IResourceStream#close() -
  https://issues.apache.org/jira/browse/WICKET-4600.
 
  --
  Martin Grigorov
  jWeekend
  Training, Consulting, Development
  http://jWeekend.com

Re: Form and button submit order

[Carl-Eric Menzel]

On Mon, 18 Jun 2012 22:20:33 +0300
Martin Grigorov mgrigo...@apache.org wrote:

 Hi Carl-Eric,
 
 I also think that having onBeforeFormSubmit and onAfterFormSubmit in
 IFormSubmitter will make this much clearer for the user.
 Deprecate onSubmit() in 1.5 and remove it for 6.0.

I agree it is clearer - the only thing that still bugs me is that the
extension interface for the new methods (so far I'm calling it
IBeforeAndAfterFormSubmitter extends IFormSubmitter) is not *that*
nice. It's only for 1.5 compatibility though and won't show up in 6.

 On Fri, Jun 15, 2012 at 5:30 PM, Carl-Eric Menzel
 cmen...@wicketbuch.de wrote:
  Since it hit me today too, I had a look at this ticket:
 
  https://issues.apache.org/jira/browse/WICKET-4575
 
  Thinking a bit too fast maybe, I implemented a simple and clean
  solution based on an enum BEFORE_FORM and AFTER_FORM that allows an
  ISubmittingComponent to choose whether it wants to run before or
  after the form.
 
  In the comments on that ticket I had a look at how to offer that in
  1.5 too, and whether a different approach might be better. I'll be
  able to take another look at this tonight. Any opinions?
 
  Carl-Eric
 
 
 

Re: Carl-Eric Menzel is now part of the Wicket team!

[Carl-Eric Menzel]

On Thu, 26 Apr 2012 11:55:33 +0200
Martijn Dashorst martijn.dasho...@gmail.com wrote:

 Carl-Eric Menzel has been invited to join the Wicket team. Please
 welcome Carl-Eric!


Yay! Thanks everyone! :-)

Carl-Eric

Re: [Vote] Release Apache Wicket 1.5.6 (build 2)

[Carl-Eric Menzel]

+1 for 1.5.6. Tested build and my (small) training application, so at
least all the central parts work. Our main production app isn't migrated
yet so I can't test it yet.

I agree with Dan's assessment if WICKET-4525, that doesn't seem to be a
bug.

Carl-Eric

On Mon, 30 Apr 2012 23:41:37 +0200
Sven Meier s...@meiers.net wrote:

 +1 for 1.5.6
 
 Sven
 
 On 04/30/2012 10:05 PM, Martin Grigorov wrote:
  Can someone of the Wicket devs verify the problem and cancel the
  release? Or +1 it otherwise ...
 
  P.S. I'm on vacation without IDEs around :-)
 
  On Sun, Apr 29, 2012 at 1:34 PM, Sebastienseb...@gmail.com  wrote:
  https://issues.apache.org/jira/browse/WICKET-4525
 
  Thanks !
  Sebastien.
 
  On Sun, Apr 29, 2012 at 2:56 AM, Igor
  Vaynbergigor.vaynb...@gmail.comwrote:
 
  https://issues.apache.org/jira/browse/WICKET
 
  -igor
 
  On Sat, Apr 28, 2012 at 5:08 PM, Sebastienseb...@gmail.com
  wrote:
  Hi again... (and sorry again)
 
  This time it is a real issue I am facing with the 1.5.6 build 2
  (whereas
  it
  was working using 1.5.5).
 
  To sum up, the issue is related to an http-post, where a
  required text field is sent through a form by a javascript
  'submit' command, which command has been transmitted to the
  client side via an ajax-behavior, and iif the validation has
  failed at the very first try. In that case, the behavior's
  script transmitted to the client seems to not be executed (the
  page is immediately re-rendered after the Invoking pre-call
  handler(s)...
  step). Despite the research I made on revolved issues for 1.5.6,
  I did
  not
  find any related issue that may cause this one.
 
  I have prepared a quickstart (and more infos about the use case)
  in case you want to look at this...
  Just tell me where I have to send/post it.
 
  Thanks and best regards,
  Sebastien.
 
 
 

WICKET-4512

[Carl-Eric Menzel]

Hi,

could one of the old-time devs please look at
https://issues.apache.org/jira/browse/WICKET-4512 ? martin-g and I
discussed this patch and it seems to be the simplest solution for this
issue. No tests break, but maybe someone knows a reason why this
wouldn't be good.

Thanks
Carl-Eric

Re: wicket 6.0 and automatic model detachment

[Carl-Eric Menzel]

At first glance I'm torn about this, to be honest. On the one hand,
yes, not having to do that would be neat. On the other hand, that makes
models even more magic to new users, and not obvious what happens.
Especially if you create a model in e.g. your constructor and just
reference it a method of an anonymous class, that would not be detected
by this.

MyComponent() {
   IModel foo = createSomeModel();
   add(new Link() { onClick() {
  // use foo model
   }});
}

This model would not be detected by reflection, as far as I can tell.
So some models would be magically detached, others wouldn't. That might
lead to more confusion than just telling people Well just detach it!.

So far we've been getting along with a simple rule: Detach the model
yourself or pass it on to someone else. Easy to remember and works
reliably. This is what I've been teaching too.

I guess I'd have to see it in practice to make up my mind really. Is it
possible to offer it as an extension or something in wicketstuff, at
least for now?

Carl-Eric
www.wicketbuch.de

On Fri, 6 Apr 2012 09:42:42 -0700
Igor Vaynberg igor.vaynb...@gmail.com wrote:

 i wrote a IDetachListener that automatically detaches any IModel
 fields found on components. is this something we would be interested
 in for core? its been running in production for a while without any
 noticeable overhead and its nice not to have to implemenet onDetach()
 all the time just to forward it to secondary models. the only downside
 is that once we introduce this feature we can never remote it because
 doing so will break code.
 
 thoughts?
 
 -igor

Re: wicket 6.0 and automatic model detachment

[Carl-Eric Menzel]

On Fri, 6 Apr 2012 10:48:35 -0700
Igor Vaynberg igor.vaynb...@gmail.com wrote:

 actually all variables referenced in such manner become fields of the
 anonymous class and are accessible via reflection.

I wasn't sure about that so before I posted my reply I did an
admittedly naive test. The variable I tried did at least not show up in
Class#getDeclaredFields. I agree it makes sense that it should be there
somewhere (that's how anon classes work) - but where does it show
up? 

Carl-Eric

Re: git and multiple workspaces with the 2 branches and 1 trunk (master?)

[Carl-Eric Menzel]

What you need is a separate working directory managed
by the same local repo. There's a script git new-workdir in contrib/
that does that for you. 
See http://nuclearsquid.com/writings/git-new-workdir/ for details.

Carl-Eric
www.wicketbuch.de

On Wed, 4 Jan 2012 16:25:32 +0100
Johan Compagner jcompag...@gmail.com wrote:

 Currently i just have 3 workspaces for wicket (1.4,1,5 and
 trunk/master)
 
 But git works with a/one working directory...
 
 thats always one of those..
 
 So is the only solution to have the remote git repo dumped three
 times on my disk?
 I don't find that very logical..
 
 And no i don't want to constantly switch, i could do that with wicket
 if really needed, but i find that annoying because i also look for
 our self (and eclipse projects also now move)
 and there i have really all kind of changes in 1 when i want to go to
 the other...
 
 And clicking between eclipse instances is way faster (i always have 3
 or more eclipse instances open on various workspaces)
 
 johan

Re: Possible security problem with isRenderAllowed(), beforeRender(), determineVisibility() and component hierarchy.

[Carl-Eric Menzel]

On Tue, 22 Nov 2011 22:39:17 -0800
Igor Vaynberg igor.vaynb...@gmail.com wrote:

 fixed in WICKET-4256

Awesome!
Is this a possible candidate to be fixed in the last 1.4 release too?

Thanks
Carl-Eric
www.wicketbuch.de

Re: Possible security problem with isRenderAllowed(), beforeRender(), determineVisibility() and component hierarchy.

[Carl-Eric Menzel]

On Mon, 21 Nov 2011 09:55:44 +0100
Daniel Stoch daniel.st...@gmail.com wrote:

 Maybe it is a related problem to this one?
 http://apache-wicket.1842946.n4.nabble.com/setRenderAllowed-called-for-invisible-components-td3790937.html

It is somewhat related, but I think setRenderAllowed should be called
for all components, since up to and including onBeforeRender visibility
can still be changed.

Carl-Eric
www.wicketbuch.de

Possible security problem with isRenderAllowed(), beforeRender(), determineVisibility() and component hierarchy.

[Carl-Eric Menzel]

Hi,

I ran into an odd problem this week. A model fed to a ListView was
calling service methods the current user wasn't allowed to use, and I
was wondering how that could happen. A panel far above this ListView in
the hierarchy had been secured (using Shiro annotations, but that turns
out to not matter at all) and was not supposed to be rendered for this
user. From this I had expected the ListView not to be rendered either,
but here it was trying to assemble itself in onBeforeRender and thus
calling the forbidden service methods.

I investigated Component and friends for a bit, and have found a
potential problem.

internalBeforeRender() checks determineVisibility() before doing
anything. So far so good. determineVisibility() then checks
isRenderAllowed() so the application's IAuthorizationStrategy can block
certain components. This is where it goes wrong though:
isRenderAllowed() only looks at FLAG_IS_RENDER_ALLOWED for performance
reasons, and that flag hasn't been set yet! internalPrepareForRender()
only calls setRenderAllowed() *after* beforeRender().

Due to this, the supposedly secure panel was going through its own
beforeRender and thus calling that ListView's beforeRender.

I think this can be a serious problem, such as in my case described
above. I'd expect that if isActionAuthorized(RENDER) is false, the
secured component should basically never get to the beforeRender phase.
My questions are now:

- Is this intentional? If yes, please explain the reasoning behind it,
  because it isn't obvious to me.

- If not, can we fix it? My intuitive suggestion would be to simply
  move the call to setRenderAllowed() from the end of
  internalBeforeRender() (prepareForRender in 1.4) to the beginning of
  that method, so beforeRender() can reliably look at that flag.

- If we can fix it, when and where do we fix it? This hit me in 1.4,
  and looking at the code it's still there in 1.5. I'd *really* like it
  fixed in the last 1.4 release, and certainly in 1.5, given that this
  has the potential to impact security.

  It's not an API break, but I'm not sure whether the implications for
  application behavior are tolerable for all existing applications. On
  the other hand, it seems to be a real security problem, so maybe the
  change is justified. I'd like some core dev opinions please :-)

If this is in fact a bug, I'm of course willing to provide a ticket and
a patch :-)

Thanks!

Carl-Eric
www.wicketbuch.de

Possible security problem with isRenderAllowed(), beforeRender(), determineVisibility() and component hierarchy.

[Carl-Eric Menzel]

Hi,

I ran into an odd problem this week. A model fed to a ListView was
calling service methods the current user wasn't allowed to use, and I
was wondering how that could happen. A panel far above this ListView in
the hierarchy had been secured (using Shiro annotations, but that turns
out to not matter at all) and was not supposed to be rendered for this
user. From this I had expected the ListView not to be rendered either,
but here it was trying to assemble itself in onBeforeRender and thus
calling the forbidden service methods.

I investigated Component and friends for a bit, and have found a
potential problem.

internalBeforeRender() checks determineVisibility() before doing
anything. So far so good. determineVisibility() then checks
isRenderAllowed() so the application's IAuthorizationStrategy can block
certain components. This is where it goes wrong though:
isRenderAllowed() only looks at FLAG_IS_RENDER_ALLOWED for performance
reasons, and that flag hasn't been set yet! internalPrepareForRender()
only calls setRenderAllowed() *after* beforeRender().

Due to this, the supposedly secure panel was going through its own
beforeRender and thus calling that ListView's beforeRender.

I think this can be a serious problem, such as in my case described
above. I'd expect that if isActionAuthorized(RENDER) is false, the
secured component should basically never get to the beforeRender phase.
My questions are now:

- Is this intentional? If yes, please explain the reasoning behind it,
  because it isn't obvious to me.

- If not, can we fix it? My intuitive suggestion would be to simply
  move the call to setRenderAllowed() from the end of
  internalBeforeRender() (prepareForRender in 1.4) to the beginning of
  that method, so beforeRender() can reliably look at that flag.

- If we can fix it, when and where do we fix it? This hit me in 1.4,
  and looking at the code it's still there in 1.5. I'd *really* like it
  fixed in the last 1.4 release, and certainly in 1.5, given that this
  has the potential to impact security.

  It's not an API break, but I'm not sure whether the implications for
  application behavior are tolerable for all existing applications. On
  the other hand, it seems to be a real security problem, so maybe the
  change is justified. I'd like some core dev opinions please :-)

If this is in fact a bug, I'm of course willing to provide a ticket and
a patch :-)

Thanks!

Carl-Eric
www.wicketbuch.de

Re: wicket conversation/workspace

[Carl-Eric Menzel]

I have to admit I've never quite understood the need for seam-style
conversations in Wicket. Whenever I need to do some kind of
defined workflow, I simply use appropriate IModel instances that get
passed around between the participating components. What is the use
case of using a conversation construct over models?

Carl-Eric
www.wicketbuch.de

On Thu, 14 Apr 2011 23:14:14 -0700
Igor Vaynberg igor.vaynb...@gmail.com wrote:

 seam-wicket provides a full implementation.
 
 if you want clean you can build it yourself, its not too difficult.
 subclass session and inside put a map of conversationId,conversation
 and manage that map however you see fit in your app.
 
 -igor
 
 
 On Thu, Apr 14, 2011 at 10:55 PM, YK linux_2...@yahoo.fr wrote:
  Are you planning to develop a conversation/workspace module ?
 
  What I mean by conversation is a session portion or
  manageable/controllable mini session
  that can be started and finished programmatically.
 
  This allows building multi-step programs and/or workflow and permits
  generally memory (objects in session) management.
 
  I know that wicket-seam provides this (partially) but what I would
  like to know is : could we have a pure
  wicket one ? and if it is feasible.
 
 
  Thanks
 
  --
  View this message in context:
  http://apache-wicket.1842946.n4.nabble.com/wicket-conversation-workspace-tp3451294p3451294.html
  Sent from the Forum for Wicket Core developers mailing list archive
  at Nabble.com.
 

Re: final Page.onInitialize()

[Carl-Eric Menzel]

On Tue, 1 Feb 2011 08:52:03 -0800
Igor Vaynberg igor.vaynb...@gmail.com wrote:

 apparently some people also use it as a post-construct callback, which
 sort of makes sense. for example, to call overridable factory methods,
 which you cannot do from the constructor.
 
 the solution is to delay all calls to oninitialize until just before
 the very first call to onconfigure.

You have just described both my usecase and the patch I submitted a
while ago ;-)

 i have mixed feelings about it
 because essentially when instantiating a new page you get an
 incomplete/lazy-initialized object and it is hard to have any useful
 methods on it that configure it further.

I understand the mixed feelings. However, I rarely find myself
instantiating a Page class manually and then doing anything other than
handing it to setResponsePage(). I think this could be sufficiently
guarded by putting a good explanation on onInitialize's javadoc.
Besides, by this logic, Component is also incompletely initialized
until the moment it gets added to the page.

In the meantime since the patch mentioned above was rejected, our
project went back to doing onBeforeRender with manual guard against
repeated post-construct initialization. This works. It has the
same drawback of being incomplete for a short duration, and it mixes
actual beforeRender stuff with late initialization, which can get
confusing. I think onInitialize would at least relocate these things to
a clearly visible and obvious spot. The bottom line is, you need to
know what you are doing if you do post-construct initialization, no
matter where you put that stuff. That said, it could be a more visible
spot than onBeforeRender ;-)

I'm +0.5 for going with my patch. 

Pro: - nice to have
 - makes Page consistent with Component

Con: - may break if an uninitialized Page (or Component!) is used
   carelessly. With Component this problem exists today already,
   at least until the component is added to its page. With Page it
   will not break existing code, since Page's onInitialize doesn't
   work properly at all at the moment.

 - not having it is not a showstopper


Carl-Eric
www.wicketbuch.de

Re: [discuss] How to resolve wicket aggregate classes / sources jar issues

[Carl-Eric Menzel]

On Mon, 24 Jan 2011 15:47:58 -0800
Igor Vaynberg igor.vaynb...@gmail.com wrote:

 [+1] - Just forget about the aggregated wicket.jar and modify the
 wicket...
 

Non-binding, just my opinion:

[+1] - Just forget about the aggregated wicket.jar and modify the
wicket...

Carl-Eric
www.wicketbuch.de

Re: [jira] Resolved: (WICKET-3218) Component#onInitialize is broken for Pages

[Carl-Eric Menzel]

On Fri, 17 Dec 2010 11:05:01 -0500 (EST)
Igor Vaynberg (JIRA) j...@apache.org wrote:

 i made the decision to make the method final in page. i think this
 makes more sense then delaying the call because by the time the
 page's constructor is finished the page should be initialized, eg
 code like this is commong
 
 EditUserPage page=new EditUserPage(user);
 page.switchToAddressEditMode();
 
 switchToAddressEditMode() may depend on certain components being
 added to the hierarchy and if they are added in oninitialize() which
 is delayed the method may fail.
 
 thus, the principle of least surprise dictates we make it final in
 page.

Well if your superclass is doing things you don't know about then you
are usually screwed anyway. Is this case really that common? Making it
final at least makes it obvious that onInitialize doesn't work, however:

It leaves a question open: What is the official approach
that replaces onInitialize for a page? What if I want to provide an
extension point for sub-pages but still need to give them a chance to
have their own constructor run first?

Typical example with panel-based layout in a super page:

class AbstractLayoutPage {
  public AbstractLayoutPage() {
 add(getLeftColumn());
 add(getRightColumn());
  }
  
  protected Component getLeftColumn() {...}
  protected Component getRightColumn() {...}
}

class SomeConcretePage {
   private final Object someImportantObject;
   public SomeConcretePage(Object o) {
 this.someImportantObject = o;
   }

   @Override protected Component getLeftColumn() {
 return new CustomLeftColumn(this.someImportantObject);
 // fails because someImportantObject isn't initialized.
   }
}

With a delayed onInitialize (or my original proposal for a separate
onPageInitialize) I could do this in onInitialize. Right now I have
no way of doing this safely. How can I have an initialization in page
after the constructors are done? Without some sort of change to
onInitialize or a new event entirely I only see doing it in
onBeforeRender and manually keeping track of whether it's been done
already or not.

Personally I have seen the overridable Panel approach much more often
than hoping without looking that the superclass does its construction in
a particular order.

I'm not saying that my patch is the perfect solution - but I'd really
like an official hint at how to do something after the page
constructors.

Thanks
Carl-Eric
www.wicketbuch.de

Re: Future hosting of wicket stuff

[Carl-Eric Menzel]

 Moving to Github

+1 for github. It makes distributed development so much easier. As for
staying close to Apache... apache.org is only a link away.

Carl-Eric
www.wicketbuch.de

Re: Wicket and OpenJdk

[Carl-Eric Menzel]

Wicket won't compile with OpenJDK6. You have to use an 1.5 JDK. I had a
proposal to use Maven-Toolchains to solve this, but now I'm using a
custom mvn15 script that uses JDK1.5, like Martin Grigorov (I think)
suggested.

Maybe the JDK1.5 requirement ought to be documented somewhere.

Carl-Eric
www.wicketbuch.de

On Sun, 5 Dec 2010 18:25:41 +0100
Martin Grigorov mgrigo...@apache.org wrote:

 com.sun.image.codec.jpeg.JPEGImageEncoder.encode(BufferedImage) throws
 IOException
 with Oracle JDK it prints warning about the usage of com.sun.*
 
 On Sun, Dec 5, 2010 at 6:18 PM, andrea del bene
 andrea.on@libero.itwrote:
 
  Hi,
 
  I'm having some troubles trying to compile Wicket main trunk with
  OpenJdk under Ubuntu 10.10 64 bit. Is there any problem with this
  Java distribution? The compilation error a get is relative to class
  ResourceTestPage.java at
  testing/wicket-threadtest/src/main/java/org/apache/wicket/threadtest/apps/app1/
  The error message is the following:
 
  testing/wicket-threadtest/src/main/java/org/apache/wicket/threadtest/apps/app1/ResourceTestPage.java:[78,4]
  exception java.io.IOException is never thrown in body of
  corresponding try statement
 
  Everything goes fine under my virtual box with WinXp 32 with Oracle
  JDK.
 
  Thank you.
 

Re: Wicket and OpenJdk

[Carl-Eric Menzel]

On Sun, 5 Dec 2010 19:09:55 +0100
Martin Grigorov mgrigo...@apache.org wrote:

 Compiling with Oracle JDK 1.6 works fine.

That's interesting. I thought Oracle and OpenJDK were (at least for now)
compatible.

 Wicket 1.4/1.5 *have* to support JDK 1.5 so we can use anything
 specific for JDK 1.6.

I know, that's fine with me. 

 Andrea, I just changed it to catch Exception instead of IOException.
 Should be OK for OpenJDK now.

On the other hand, should there be a test that checks for 1.5, just to
make sure it's compiled with 1.5? Probably more effort than it's worth
though.

Carl-Eric
www.wicketbuch.de

Re: [bug?] onInitialize() for Pages?

[Carl-Eric Menzel]

Hi Pedro,

thanks for your reply.

I find the current behavior of onInitialize in Pages *very* surprising
and unexpected. It doesn't say anywhere in the documentation that using
onInitialize prohibits use of constructors.

Also, this only seems to affect pages. In all other components it seems
to work fine, which makes this behavior rather inconsistent.

Also, this quickstart is of course somewhat simplified. My real-world
issue is that I am extending from a chain of superclasses that all do
something in their constructors. It's not realistic to switch the
entire hierarchy from constructors to onInitialize.

Also again ;-), right now onInitialize for Pages is broken. For all
other components, onInitialize is called *after* all constructors have
run. Only for Pages this is done in the middle of the constructor. 

I think either Page should have a final onInitialize implementation to
really prohibit onInitialize being used at all, or there should be a
special case for Page causing onInitialize to be called just before
onBeforeRender. This would be consistent with Java object construction
and also consistent with the contract of onInitialize, which simply
says it is called sometime before onBeforeRender().

Would that be an acceptable solution? Want me to provide a patch?

Thanks
Carl-Eric
www.wicketbuch.de

On Wed, 1 Dec 2010 20:31:35 -0200
Pedro Santos pedros...@gmail.com wrote:

 Hi Carl, you are mixing two different initializations strategies,
 that is why you are finding it weird. If you are using an overwritten
 onInitialize to initialize your component, do all your initialization
 there, even add your component's children.
 
 For example, your quickstart works fine as:
 @Override
 protected void onInitialize() {
 super.onInitialize();
 add(new Label(message,
 If you see this message wicket is properly
 configured and running));
 if (!constructorDone) {
 throw new IllegalStateException();
 }
 }
 
 On Wed, Dec 1, 2010 at 7:24 PM, cmen...@wicketbuch.de wrote:
 
  Hi,
 
  we just ran into an interesting problem. We are using inheritance a
  lot in our pages, but at one point we need something in the super
  page that depends on the constructor of the sub page. Just like
  with regular components, I thought I'd just use onInitialize() for
  that.
 
  Unfortunately, that didn't work:
 
  at
  comMySubPage.onInitialize(...)
  at org.apache.wicket.Component.fireInitialize(Component.java:4050)
  at
  org.apache.wicket.MarkupContainer.initialize(MarkupContainer.java:413)
  at org.apache.wicket.Page.componentAdded(Page.java:1589) at
  org.apache.wicket.MarkupContainer.addedComponent(MarkupContainer.java:979)
  at org.apache.wicket.MarkupContainer.add(MarkupContainer.java:142)
  at comMySuperPage.init(...)
 
  See the quickstart at
  https://github.com/duesenklipper/wicket-oninitialize
 
  or just do this in the HomePage of any Wicket app:
 
 private final boolean constructorDone;
 public HomePage(final PageParameters parameters) {
 add(new Label(message, blah));
 
 this.constructorDone = true;
 }
 
 @Override
 protected void onInitialize() {
 super.onInitialize();
 if (!constructorDone) {
 throw new IllegalStateException();
 }
 }
 
  As soon as I add() the first component to the page in the super
  constructor, the page's initialize() is called, which fires
  onInitialize. At this time, my onInitialize can't do anything, since
  not even the super constructor has been run completely!
 
  Should this really happen this way? I.e., should the Page be
  initialized at this point, or should the page's onInitialize call be
  deferred later? Or is onInitialize not the right spot to do this
  for a page - what would the right way be then?
 
  Thanks
  Carl-Eric
  www.wicketbuch.de
 
 
 
 

Re: [bug?] onInitialize() for Pages?

[Carl-Eric Menzel]

 Make onInitialize final on pages is an good idea. It is designed to
 children have a guaranty that the path to page exists, not to
 guaranty that an parent has all its children on the hierarchy
 already. So it is fairly more useful to children than for parent
 components. I just don't know if that change implies in rename the
 onInitialize to notifyHierarchy or similar.

While I think making onInitialize final for Pages is a *valid*
solution, I think it is not really useful. I still can have the same
problem in Pages that onInitialize is trying to solve for Components:
That some things can only be done once *all* constructors have run.
With Components, I can use onInitialize. I would really like to be able
to do the same for Pages.

Carl-Eric
www.wicketbuch.de

Re: [announce] Pedro Santos added to Wicket PMC / Committer

[Carl-Eric Menzel]

On Mon, 22 Nov 2010 22:08:10 -0500
Jeremy Thomerson jer...@wickettraining.com wrote:

 I'd just like to pass this on to everyone on the list.  Pedro Santos
 has been added as a committer and PMC member for Apache Wicket.  Pedro

Congratulations!

Carl-Eric
www.wicketbuch.de

Introduce Maven Toolchains?

[Carl-Eric Menzel]

Hi,

Trying to compile Wicket 1.4.13 recently, I ran into the problem that
ResourceTestPage in wicket-threadtest failed to compile, since it tries
to catch an IOException in line 87. The only line in the catch block,
JPEGImageEncoder.encode(image), doesn't declare that exception, and so
the compiler rejects the catch.

Turns out this is a change in JDK 1.6. After pulling in some old Ubuntu
repositories and actually installing an old 1.5 JDK, and temporarily
setting my JAVA_HOME to that, the build worked fine.

It would be easy to just change this catch clause to Throwable instead
of IOException, that way both JDKs would be satisfied. However, when I
hack on Wicket, I don't want to inadvertently introduce dependencies to
JDK 1.6. The maven compiler settings only check for syntax
compatibility, not API compatibility, so this could easily happen.

On the other hand, I don't want to be setting and re-setting my
JAVA_HOME every time I want to build Wicket, so I looked for a way to
tell Maven what JDK to use, without hardcoding my path into Wicket's
pom.xml.

It turns out that you can't do anything like that in your local
settings.xml. Sometimes I really hate Maven ;-)

There is a plugin called maven-toolchains[1], however, that makes this
possible. You add this plugin to the projects, and add a rather simply
toolchains.xml to your ~/.m2/, and then you can define things like JDK
version: 1.5 or even vendor: sun. I wouldn't do the latter, but I
found that this way I could have Maven automatically pick my JDK 1.5
installation for Wicket, and compile everything else with 1.6.

I'll provide a patch and an example toolchains.xml. What do you think,
should this be integrated? It would amount to a one-time change to each
developer's environment (at least for those that don't use toolchains
yet).

See https://issues.apache.org/jira/browse/WICKET-3182 for the patch and
let me know what you think :-)

Just saw this before I send this mail: Martin Grigorov commented in
JIRA already that he uses a modified mvn bash script that sets
JAVA_HOME. That would be an acceptable fallback solution in case you
guys don't like my proposal. My one objection to the separate script
is that I'd need to remember to type mvn15 instead of mvn. I like to
reduce human interaction with the build as much as possible because I
know how forgetful I can be ;-)

Carl-Eric
www.wicketbuch.de

[1] http://maven.apache.org/guides/mini/guide-using-toolchains.html

Re: JRebel and wicket

[Carl-Eric Menzel]

On Thu, 18 Nov 2010 13:52:32 +0100
Martijn Dashorst martijn.dasho...@gmail.com wrote:

 Now we could ask folks to use addOrReplace() instead of add(), or we
 could relax the multi add restriction to alleviate this problem.
 
 I wouldn't be against relaxing add() and deprecating addOrReplace().
 
 Now calling onInitialize again on a constructed component might open
 up another can of worms.
 
 Is this something worth pursuing? Or should we just write an article
 with how to do jrebel no-redeploy wicket coding?

Good question. So far I'm +0.5 on just documenting it.

Is it widespread enough to warrant changing the way Wicket works just to
cater to a non-free(!) development tool? It seems to me that it would
rather be an issue for the JRebel guys to address within their product.

I'm not using JRebel at the moment, but according to what James wrote,
it seems to work nicely even without this.

Carl-Eric
www.wicketbuch.de

Re: remove oninitialize/onconfigure from 1.4.x?

[Carl-Eric Menzel]

Definitely +1 from me for keeping these methods in 1.4.x, with the
additional scope-narrowing changes from Johan. Good ideas! These new
methods will make some things much easier for us. I'm not sure how
quickly we could move to 1.5 once it comes out.

On a related note, is there any documentation on what is changing
between 1.4.x and 1.5, both on the surface and internally?

Thanks
Carl-Eric

-- 
Carl-Eric Menzel
http://www.wicketbuch.de/


On Fri, 23 Jul 2010 10:38:47 +0200
Johan Compagner jcompag...@gmail.com wrote:

 we (servoy) dont care much about those changes, they can be left in
 (we dont use it and they also dont give us a problem (after my fix ;)
 )
 
 
 the only problem is by the way onInitialize and onConfigure()
 
 Because initialize and also doInitialize() are package scope so they
 are not a problem as far as i know... for example doinitialize() is
 final but a subclass of component in another package can just create
 such a method just fine...
 
 configure() you made public final.. i think we just should do the
 same, make it package scope final...
 then that method shouldnt also be a big problem.
 
 The it is just the 2 overridable protected methods onInitialize and
 onConfigure
 
 johan
 
 
 On Thu, Jul 22, 2010 at 19:33, Igor Vaynberg
 igor.vaynb...@gmail.com wrote:
  i just thought of something, i added oninitialize and onconfigure
  features to 1.4.x as well as trunk, but they can create an
  incompatibility for 1.4.x users if they have declared a method on
  their components with the same name.
 
  impacted method names are component#configure(), onConfigure(),
  initialize(), onInitialize().
 
  should we remove these features from 1.4.x to remove the chance of
  an incompatibility?
 
  -igor
 

Re: remove oninitialize/onconfigure from 1.4.x?

[Carl-Eric Menzel]

Great, thanks!

On Fri, 23 Jul 2010 14:55:06 +0200
Martin Grigorov mgrigo...@apache.org wrote:

 https://cwiki.apache.org/WICKET/migration-to-wicket-15.html
 
 On Fri, Jul 23, 2010 at 2:38 PM, Carl-Eric Menzel
 cmen...@wicketbuch.dewrote:
 
  Definitely +1 from me for keeping these methods in 1.4.x, with the
  additional scope-narrowing changes from Johan. Good ideas! These new
  methods will make some things much easier for us. I'm not sure how
  quickly we could move to 1.5 once it comes out.
 
  On a related note, is there any documentation on what is changing
  between 1.4.x and 1.5, both on the surface and internally?
 
  Thanks
  Carl-Eric
 
  --
  Carl-Eric Menzel
  http://www.wicketbuch.de/
 
 
  On Fri, 23 Jul 2010 10:38:47 +0200
  Johan Compagner jcompag...@gmail.com wrote:
 
   we (servoy) dont care much about those changes, they can be left
   in (we dont use it and they also dont give us a problem (after my
   fix ;) )
  
  
   the only problem is by the way onInitialize and onConfigure()
  
   Because initialize and also doInitialize() are package scope so
   they are not a problem as far as i know... for example
   doinitialize() is final but a subclass of component in another
   package can just create such a method just fine...
  
   configure() you made public final.. i think we just should do the
   same, make it package scope final...
   then that method shouldnt also be a big problem.
  
   The it is just the 2 overridable protected methods onInitialize
   and onConfigure
  
   johan
  
  
   On Thu, Jul 22, 2010 at 19:33, Igor Vaynberg
   igor.vaynb...@gmail.com wrote:
i just thought of something, i added oninitialize and
onconfigure features to 1.4.x as well as trunk, but they can
create an incompatibility for 1.4.x users if they have declared
a method on their components with the same name.
   
impacted method names are component#configure(), onConfigure(),
initialize(), onInitialize().
   
should we remove these features from 1.4.x to remove the chance
of an incompatibility?
   
-igor
   
 
 

Re: wicket 1.5 build is failing because of 1.6 deps...

[Carl-Eric Menzel]

On Tue, 15 Dec 2009 11:44:23 +0100
Martijn Dashorst martijn.dasho...@gmail.com wrote:

 I was going to propose a vote in that direction... as JDK 1.5 has been
 shelved...
 

It'll be years until Java 1.6 is as common as 1.5 is now. There are many
organizations who have only just completed the move to 1.5. I think
going to a strict requirement for Java 1.6 would be a really bad idea,
especially since it does not offer as many significant new benefits as
1.5 did.

Offering 1.6-specific features in a separate jar would be a simple and
pretty good solution, I think. Stuff like the typesafe model would thus
be available for those who need it, without leaving anybody needlessly
stranded.

Carl-Eric

Re: wicket 1.5 build is failing because of 1.6 deps...

[Carl-Eric Menzel]

As far as I remember (and please correct me if I'm wrong), support
and updates for Wicket 1.3 were ended rather quickly after the release
of 1.4. That's okay, since the team has limited resources. But it
becomes a pretty serious problem if that means you'll cut off everybody
who can't yet move up to Java 1.6.

Java 1.5 adoption was pretty much everywhere when Wicket moved up to
it. The same is not true for Java 1.6 at this time.

Carl-Eric

-- 
Carl-Eric Menzel
Das neue deutschsprachige Wicketbuch:
 Wicket: Komponentenbasierte Webanwendungen in Java
 http://www.wicketbuch.de/

On Tue, 15 Dec 2009 13:40:50 +0100
Korbinian Bachl - privat korbinian.ba...@whiskyworld.de wrote:

 1.5 will be a major one, not minor - so where's the point?
 
 Best,
 
 Korbinian
 
 Carl-Eric Menzel schrieb:
  Because, from their (admittedly conservative) point of view, you
  don't move essential systems to a platform before you really know
  it. Or before your tool vendor finally manages to update their
  product to be compatible with 1.5. These are organizations that
  have to be extremely careful. Why do you think Sun is still
  offering paid support for 1.5? 
  
  It doesn't really matter why they are sticking with 1.5, however.
  What really matters is this: There are organizations for whom
  stability in the core is more important than having the new
  features. At the same time, however, they want to be able to update
  less essential things like a GUI framework for as long as possible.
  If you tell them now they won't be able to use Wicket after the
  next minor(!) release and won't get any support for the old
  version, they'll go ahead and use Struts. Okay, that last one is
  maybe a bit exaggerated, but you get what I mean.
  
  Carl-Eric
  

Re: wicket 1.5 build is failing because of 1.6 deps...

[Carl-Eric Menzel]

My point is not the version numbering of Wicket, nor the upgrading
policy of our customers. You can spend endless hours debating whether
it makes sense or not to stick with 1.5.

The point is that they *will stick to 1.5* no matter what we discuss
here, for at least 2-3 more years.

Will there be support and updates for Wicket 1.4 after 1.5 is out? If
not, we're facing a potentially serious problem with these customers.

And additionally, I think there was an extremely good case for Wicket
going to Java 1.5: Generic Models. What is the case to require Java 1.6
for Wicket core? Is it really problematic to keep that to a separate
feature jar?

Carl-Eric

-- 
Carl-Eric Menzel
Das neue deutschsprachige Wicketbuch:
 Wicket: Komponentenbasierte Webanwendungen in Java
 http://www.wicketbuch.de/

On Tue, 15 Dec 2009 14:05:05 +0100
Johan Compagner jcompag...@gmail.com wrote:

 but they are throwing money away
 now they have to do that same long process twice!
 why start at all with moving to 1.5 if there is already an 1.6 ?
 
 It shouldnt be to much a of a difference for them time and money wise
 if you are now on 1.4
 and you want to move up.. Then you can just say ok we take a release
 of 1.6.. instead of one of 1.5
 picking IF you move anyway an 1.5 release when a 1.6 release is
 already long time on the market is just blowing away money
 
 we are not talking about a next minor release (that would be 1.4.x)
 but a major release (thats 1.5)
 wicket numbering is just that.. We could also call 1.5, 3.0 if you
 want (skip 2.0 because that could be confusing for the old timers)
 
 johan
 
 
 On Tue, Dec 15, 2009 at 13:37, Carl-Eric Menzel
 cmen...@wicketbuch.dewrote:
 
  Because, from their (admittedly conservative) point of view, you
  don't move essential systems to a platform before you really know
  it. Or before your tool vendor finally manages to update their
  product to be compatible with 1.5. These are organizations that
  have to be extremely careful. Why do you think Sun is still
  offering paid support for 1.5?
 
  It doesn't really matter why they are sticking with 1.5, however.
  What really matters is this: There are organizations for whom
  stability in the core is more important than having the new
  features. At the same time, however, they want to be able to update
  less essential things like a GUI framework for as long as possible.
  If you tell them now they won't be able to use Wicket after the
  next minor(!) release and won't get any support for the old
  version, they'll go ahead and use Struts. Okay, that last one is
  maybe a bit exaggerated, but you get what I mean.
 
  Carl-Eric
 
  --
  Carl-Eric Menzel
  Das neue deutschsprachige Wicketbuch:
   Wicket: Komponentenbasierte Webanwendungen in Java
   http://www.wicketbuch.de/
 
 
 
  On Tue, 15 Dec 2009 13:12:45 +0100
  Johan Compagner jcompag...@gmail.com wrote:
 
   so recently they moved to 5?
   at a time that 6 is already almost 3 years there?
   how stupid is that?
  
   Why if you move you move to something that is already a dinosaur ?
  
   On Tue, Dec 15, 2009 at 13:03, Carl-Eric Menzel 
   cm.wic...@users.bitforce.com wrote:
  
   
I only know about our customers, who are mostly medium to large
financial corporations. Very conservative. There's not one among
them who is running on 1.6 yet. As I said, some have only very
recently managed to move up to 1.5. We are finally getting some
of them to use Wicket. If you now add a hard dependency on Java
1.6, that will make things rather difficult in this space.
   
Do you really need it for anything in core? I know that running
on 1.6 is nice performance-wise, but that is not a good reason
to ditch runtime compatibility. Don't get me wrong, I'd love to
use 1.6 as well. But I really think that it should stay out of
the core for quite some time still.
   
Carl-Eric
   
On Tue, 15 Dec 2009 12:39:47 +0100
Martijn Dashorst martijn.dasho...@gmail.com wrote:
   
 I think that Java 6 adoption was much faster than 1.5
 adoption. Compatibility is pretty good, but you get an
 immediate 30% performance gain.

 Martijn

 On Tue, Dec 15, 2009 at 12:36 PM, Carl-Eric Menzel
 cm.wic...@users.bitforce.com wrote:
  On Tue, 15 Dec 2009 11:44:23 +0100
  Martijn Dashorst martijn.dasho...@gmail.com wrote:
 
  I was going to propose a vote in that direction... as JDK
  1.5 has been shelved...
 
 
  It'll be years until Java 1.6 is as common as 1.5 is now.
  There are many organizations who have only just completed
  the move to 1.5. I think going to a strict requirement for
  Java 1.6 would be a really bad idea, especially since it
  does not offer as many significant new benefits as 1.5 did.
 
  Offering 1.6-specific features in a separate jar would be a
  simple and pretty good solution, I think. Stuff like the
  typesafe model would thus be available

New german Wicket book (was: Re: wicket 1.5 build is failing because of 1.6 deps...)

[Carl-Eric Menzel]

Since the question about availability came up now :-)

We (Roland Förther, Carl-Eric Menzel, Olaf Siefart) just released our
new german-language Wicket book, called Wicket: Komponentenbasierte
Webanwendungen in Java, published by dpunkt Verlag.

I was told a few minutes ago that it was shipped to retailers and
distributors like Amazon.de yesterday. It should probably be available
in the stores by the end of this week or at the latest early next week.

Carl-Eric

-- 
Carl-Eric Menzel
Das neue deutschsprachige Wicketbuch:
 Wicket: Komponentenbasierte Webanwendungen in Java
 http://www.wicketbuch.de/

On Tue, 15 Dec 2009 13:52:32 +0100
Michael Mosmann mich...@mosmann.de wrote:

 Am Dienstag, den 15.12.2009, 13:39 +0100 schrieb Carl-Eric Menzel:
  Carl-Eric Menzel
  Das neue deutschsprachige Wicketbuch:
   Wicket: Komponentenbasierte Webanwendungen in Java
   http://www.wicketbuch.de/
 
 Hi,
 
 .. bei Amazon ist es immer noch nicht lieferbar. Bei dpunkt gibt es
 keine Entsprechende Info.. da ich lieber bei Amazon bestellen würde
 hier meine Frage: Ist es über dpunkt lieferbar? Wann ist es über
 Amazon lieferbar?
 
 Danke:)
 
 Michael Mosmann
 
 

Re: wicket 1.5 build is failing because of 1.6 deps...

[Carl-Eric Menzel]

On Tue, 15 Dec 2009 14:37:41 +0100
Martijn Dashorst martijn.dasho...@gmail.com wrote:

 I don't have a Java 5 JDK anymore on my system. It was removed by
 Apple. Java 5 has been marked EOL: which essentially means dead.
 deceased. terminated. passed on. ceased to be. expired and gone to
 meet 'is maker. a stiff. bereft of life. rests in peace. IT'S AN
 EX-JDK!

I know that, and I completely agree. I would much rather work on 1.6
than anything older, but currently I can't do that. All I'm saying is
that there is a potentially large group of users that won't be able to
follow you/us into 1.6-land any time soon.

 We don't get paid by any corporation to provide support to wicket. If
 your customers want to pay my salary for the next 5 years or so, I'm
 happy to work on Wicket full time and maintain obsolete Java code for
 them. But they won't. They just get stuff for free...

As I said, it's perfectly reasonable for a relatively small team like
the Wicket devs to focus on one version. I'm just pointing out things
that should be known to make a conscious decision.

Carl-Eric

-- 
Carl-Eric Menzel
Das neue deutschsprachige Wicketbuch:
 Wicket: Komponentenbasierte Webanwendungen in Java
 http://www.wicketbuch.de/

Re: [wicket 1.5] removing page version manager

[Carl-Eric Menzel]

On Fri, 2 Oct 2009 14:03:05 -0700
Igor Vaynberg igor.vaynb...@gmail.com wrote:

 can we yank ipageversionmanager and ichange out of 1.5? it has always
 been broken because no one implements ichange objects to keep the page
 state consistent.

How exactly is it broken? Just that nobody uses it, or that it actually
doesn't work, or causes more headaches than it's worth?

 the downside is that if someone is using httpsessionstore they will
 take a bigger hit on session usage because every version is serialized
 in its entirety. the up side is that it will actually work and the
 code can be vastly simplified.
 
 any concerns?

Only that I've just written a few pages about how to use it, for our
book ;-)

Carl-Eric

Re: [wicket 1.5] removing page version manager

[Carl-Eric Menzel]

On Fri, 2 Oct 2009 23:15:56 +0200
Matej Knopp matej.kn...@gmail.com wrote:

 Main problem with Change is that it only can do undo. It can not do
 redo which is what we need when user clicks the Forward browser
 button. Plus wicket pages can change significantly between versions.
 Representing these differences as chain of Changes is extremely
 challenging if not impossible. Plus you still have to serialize model
 objects, etc, which can cause another headache and it completely
 ignores the rest of page state like simple class variables.

Okay, I understand this. I guess I'll have to tear a few pages out of
the book ;-)

How does the back button support work then - when an older version of
the page is loaded, the component state is restored as it was, since it
was all serialized. Is this all mostly for allowing stuff like
Link#onClick() to work on old page versions? How do you avoid running
into problems when you have, for example, LoadableDetachableModels and
you have changed your domain objects. Or you have changed something not
under control of the Page, some sort of application state. Would there
be no undo mechanism at all then? At least in principle I liked the
idea of simply handing Wicket a couple of undo operations. Is it
possible to be notified when an old page version is loaded? That way
one could in principle build a custom undo. 

Carl-Eric

PS: I hope I wrote my questions clearly, it's a bit late here already...

Re: [wicket 1.5] removing page version manager

[Carl-Eric Menzel]

 Wicket version management is concerned with components. We don't
 version your domain objects (unless you keep hard references to them
 and they get serialized with the page). If you are using models
 properly most of the time when you deserialize and render the page
 your entities get reloaded so user sees the current state of your
 domain objects.

Yes I know that it's about components. I was just wondering whether
custom undo is going to be lost completely, or whether there will be
ways to react to the user going back in time.

Or are you saying this should all be done in Models? Of course, on the
other hand I'm wondering how much undo is possible anyway in a web
environment, even with a mechanism such as Change objects.

Carl-Eric

Status of SWARM?

[Carl-Eric Menzel]

Hi,

I was wondering what the current status of SWARM is. Will there be a
compatible version for the release of Wicket 1.4? If not (or not yet),
what exactly is missing to get it working with 1.4?

Thanks
Carl-Eric