Re: remove oninitialize/onconfigure from 1.4.x?

2010-07-24 Thread Martin Grigorov 
+1 for vote in users@

I just found a problem while creating new wicket-example for the new request
mappers:

java.lang.StackOverflowError
 at
org.apache.wicket.MarkupContainer.addedComponent(MarkupContainer.java:978)
 at org.apache.wicket.MarkupContainer.add(MarkupContainer.java:168)
 at
org.apache.wicket.examples.WicketExamplePage.onInitialize(WicketExamplePage.java:67)
 at org.apache.wicket.Component.initialize(Component.java:970)
 at
org.apache.wicket.MarkupContainer.initialize(MarkupContainer.java:992)
 at org.apache.wicket.Page.componentAdded(Page.java:1130)
 at
org.apache.wicket.MarkupContainer.addedComponent(MarkupContainer.java:978)
 at org.apache.wicket.MarkupContainer.add(MarkupContainer.java:168)
 at
org.apache.wicket.examples.WicketExamplePage.onInitialize(WicketExamplePage.java:67)
 at org.apache.wicket.Component.initialize(Component.java:970)
 at
org.apache.wicket.MarkupContainer.initialize(MarkupContainer.java:992)
 at org.apache.wicket.Page.componentAdded(Page.java:1130)
 at
org.apache.wicket.MarkupContainer.addedComponent(MarkupContainer.java:978)
 at org.apache.wicket.MarkupContainer.add(MarkupContainer.java:168)
 at
org.apache.wicket.examples.WicketExamplePage.onInitialize(WicketExamplePage.java:67)
 at org.apache.wicket.Component.initialize(Component.java:970)
 at
org.apache.wicket.MarkupContainer.initialize(MarkupContainer.java:992)
 at org.apache.wicket.Page.componentAdded(Page.java:1130)
 at
org.apache.wicket.MarkupContainer.addedComponent(MarkupContainer.java:978)
 at org.apache.wicket.MarkupContainer.add(MarkupContainer.java:168)
 at
org.apache.wicket.examples.WicketExamplePage.onInitialize(WicketExamplePage.java:67)
 at org.apache.wicket.Component.initialize(Component.java:970)
 at
org.apache.wicket.MarkupContainer.initialize(MarkupContainer.java:992)
 at org.apache.wicket.Page.componentAdded(Page.java:1130)
 at
org.apache.wicket.MarkupContainer.addedComponent(MarkupContainer.java:978)
 at org.apache.wicket.MarkupContainer.add(MarkupContainer.java:168)
 at
org.apache.wicket.examples.WicketExamplePage.onInitialize(WicketExamplePage.java:67)
 at org.apache.wicket.Component.initialize(Component.java:970)


In 
org.apache.wicket.examples.WicketExamplePage.onInitialize(WicketExamplePage.java:67)
I have add(header).

My fix looks is:
Index: wicket/src/main/java/org/apache/wicket/Component.java
===
--- wicket/src/main/java/org/apache/wicket/Component.java (revision 978819)
+++ wicket/src/main/java/org/apache/wicket/Component.java (working copy)
@@ -967,8 +967,8 @@
  {
  if (!getFlag(FLAG_INITIALIZED))
  {
+ setFlag(FLAG_INITIALIZED, true);
  onInitialize();
- setFlag(FLAG_INITIALIZED, true);
  }
  }

Is this ok ?

On Fri, Jul 23, 2010 at 5:45 PM, Igor Vaynberg igor.vaynb...@gmail.comwrote:

 since this has turned into more of a vote should we take it to the
 user list so we get a wider range of responses?

 -igor

 On Fri, Jul 23, 2010 at 1:50 AM, Martijn Dashorst
 martijn.dasho...@gmail.com wrote:
  +1 for Johan's changes to make the surface area of the change smaller.
 
  I didn't find onInitialize and onConfigure in our code base as well.
 
  The benefits are evident. So that is +0 from me to keep them in.
  Pushing them to only 1.5 ensures we get enough folks trying 1.5 though
  :)
 
  Martijn
 
  On Fri, Jul 23, 2010 at 10:38 AM, 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
 
 
 
 
 
  --
  Become a Wicket expert, learn from the best: http://wicketinaction.com
  Apache Wicket 1.4 increases type safety for web applications
  Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.4.8

Re: remove oninitialize/onconfigure from 1.4.x?

2010-07-24 Thread Johan Compagner 
I think that fix should be fine
The thing i have is why does Page.componentAdded() really call initialize again
Will that not happen anyway?

Also now i do see a but of weird initializing when you see the order..
In MarkupContainer.addedComponent:

if (page != null)
{
component.initialize();
}

if (page != null)
{
page.componentAdded(component);
}


so first we call component initialize. then page.componentAdded that
will call initialize on the page.
But isnt that a bit the wrong way around?

If you are in the constructor of a page and you add a component.
Then i think the component is called initialized on and
page.componentAdded will then call initialize on itself
But then the component is called initialized first before the page is
initialized
AND we are still in the constructor of the page so initialize is
suddenly called on a page that is still constructing?
(i have to test this a bit, just looking at the code quickly)

i think we should have some logic that as long as the page is not
initialized, component shouldnt also be initialized.
And for a page the same thing as for a component should happen, only
after construction the initialize is called.

johan


On Sat, Jul 24, 2010 at 11:05, Martin Grigorov mgrigo...@apache.org wrote:
 +1 for vote in users@

 I just found a problem while creating new wicket-example for the new request
 mappers:

 java.lang.StackOverflowError
  at
 org.apache.wicket.MarkupContainer.addedComponent(MarkupContainer.java:978)
     at org.apache.wicket.MarkupContainer.add(MarkupContainer.java:168)
     at
 org.apache.wicket.examples.WicketExamplePage.onInitialize(WicketExamplePage.java:67)
     at org.apache.wicket.Component.initialize(Component.java:970)
     at
 org.apache.wicket.MarkupContainer.initialize(MarkupContainer.java:992)
     at org.apache.wicket.Page.componentAdded(Page.java:1130)
     at
 org.apache.wicket.MarkupContainer.addedComponent(MarkupContainer.java:978)
     at org.apache.wicket.MarkupContainer.add(MarkupContainer.java:168)
     at
 org.apache.wicket.examples.WicketExamplePage.onInitialize(WicketExamplePage.java:67)
     at org.apache.wicket.Component.initialize(Component.java:970)
     at
 org.apache.wicket.MarkupContainer.initialize(MarkupContainer.java:992)
     at org.apache.wicket.Page.componentAdded(Page.java:1130)
     at
 org.apache.wicket.MarkupContainer.addedComponent(MarkupContainer.java:978)
     at org.apache.wicket.MarkupContainer.add(MarkupContainer.java:168)
     at
 org.apache.wicket.examples.WicketExamplePage.onInitialize(WicketExamplePage.java:67)
     at org.apache.wicket.Component.initialize(Component.java:970)
     at
 org.apache.wicket.MarkupContainer.initialize(MarkupContainer.java:992)
     at org.apache.wicket.Page.componentAdded(Page.java:1130)
     at
 org.apache.wicket.MarkupContainer.addedComponent(MarkupContainer.java:978)
     at org.apache.wicket.MarkupContainer.add(MarkupContainer.java:168)
     at
 org.apache.wicket.examples.WicketExamplePage.onInitialize(WicketExamplePage.java:67)
     at org.apache.wicket.Component.initialize(Component.java:970)
     at
 org.apache.wicket.MarkupContainer.initialize(MarkupContainer.java:992)
     at org.apache.wicket.Page.componentAdded(Page.java:1130)
     at
 org.apache.wicket.MarkupContainer.addedComponent(MarkupContainer.java:978)
     at org.apache.wicket.MarkupContainer.add(MarkupContainer.java:168)
     at
 org.apache.wicket.examples.WicketExamplePage.onInitialize(WicketExamplePage.java:67)
     at org.apache.wicket.Component.initialize(Component.java:970)
 

 In 
 org.apache.wicket.examples.WicketExamplePage.onInitialize(WicketExamplePage.java:67)
 I have add(header).

 My fix looks is:
 Index: wicket/src/main/java/org/apache/wicket/Component.java
 ===
 --- wicket/src/main/java/org/apache/wicket/Component.java (revision 978819)
 +++ wicket/src/main/java/org/apache/wicket/Component.java (working copy)
 @@ -967,8 +967,8 @@
  {
  if (!getFlag(FLAG_INITIALIZED))
  {
 + setFlag(FLAG_INITIALIZED, true);
  onInitialize();
 - setFlag(FLAG_INITIALIZED, true);
  }
  }

 Is this ok ?

 On Fri, Jul 23, 2010 at 5:45 PM, Igor Vaynberg igor.vaynb...@gmail.comwrote:

 since this has turned into more of a vote should we take it to the
 user list so we get a wider range of responses?

 -igor

 On Fri, Jul 23, 2010 at 1:50 AM, Martijn Dashorst
 martijn.dasho...@gmail.com wrote:
  +1 for Johan's changes to make the surface area of the change smaller.
 
  I didn't find onInitialize and onConfigure in our code base as well.
 
  The benefits are evident. So that is +0 from me to keep them in.
  Pushing them to only 1.5 ensures we get enough folks trying 1.5 though
  :)
 
  Martijn
 
  On Fri, Jul 23, 2010 at 10:38 AM, Johan Compagner jcompag...@gmail.com
 wrote:
  we (servoy) dont care much

Re: remove oninitialize/onconfigure from 1.4.x?

2010-07-24 Thread Martijn Dashorst 
Given these nuances, and the binary incompatibilty, shouldn't we just
revert for 1.4.x and ensure proper working in 1.5?

It's not that folks are unable to create awesome apps with 1.4 without
these changes. I'd rather not introduce subtle bugs into 1.4.x at this
stage.

Martijn

On Sat, Jul 24, 2010 at 11:19 AM, Johan Compagner jcompag...@gmail.com wrote:
 I think that fix should be fine
 The thing i have is why does Page.componentAdded() really call initialize 
 again
 Will that not happen anyway?

 Also now i do see a but of weird initializing when you see the order..
 In MarkupContainer.addedComponent:

                if (page != null)
                {
                        component.initialize();
                }

                if (page != null)
                {
                        page.componentAdded(component);
                }


 so first we call component initialize. then page.componentAdded that
 will call initialize on the page.
 But isnt that a bit the wrong way around?

 If you are in the constructor of a page and you add a component.
 Then i think the component is called initialized on and
 page.componentAdded will then call initialize on itself
 But then the component is called initialized first before the page is
 initialized
 AND we are still in the constructor of the page so initialize is
 suddenly called on a page that is still constructing?
 (i have to test this a bit, just looking at the code quickly)

 i think we should have some logic that as long as the page is not
 initialized, component shouldnt also be initialized.
 And for a page the same thing as for a component should happen, only
 after construction the initialize is called.

 johan


 On Sat, Jul 24, 2010 at 11:05, Martin Grigorov mgrigo...@apache.org wrote:
 +1 for vote in users@

 I just found a problem while creating new wicket-example for the new request
 mappers:

 java.lang.StackOverflowError
  at
 org.apache.wicket.MarkupContainer.addedComponent(MarkupContainer.java:978)
     at org.apache.wicket.MarkupContainer.add(MarkupContainer.java:168)
     at
 org.apache.wicket.examples.WicketExamplePage.onInitialize(WicketExamplePage.java:67)
     at org.apache.wicket.Component.initialize(Component.java:970)
     at
 org.apache.wicket.MarkupContainer.initialize(MarkupContainer.java:992)
     at org.apache.wicket.Page.componentAdded(Page.java:1130)
     at
 org.apache.wicket.MarkupContainer.addedComponent(MarkupContainer.java:978)
     at org.apache.wicket.MarkupContainer.add(MarkupContainer.java:168)
     at
 org.apache.wicket.examples.WicketExamplePage.onInitialize(WicketExamplePage.java:67)
     at org.apache.wicket.Component.initialize(Component.java:970)
     at
 org.apache.wicket.MarkupContainer.initialize(MarkupContainer.java:992)
     at org.apache.wicket.Page.componentAdded(Page.java:1130)
     at
 org.apache.wicket.MarkupContainer.addedComponent(MarkupContainer.java:978)
     at org.apache.wicket.MarkupContainer.add(MarkupContainer.java:168)
     at
 org.apache.wicket.examples.WicketExamplePage.onInitialize(WicketExamplePage.java:67)
     at org.apache.wicket.Component.initialize(Component.java:970)
     at
 org.apache.wicket.MarkupContainer.initialize(MarkupContainer.java:992)
     at org.apache.wicket.Page.componentAdded(Page.java:1130)
     at
 org.apache.wicket.MarkupContainer.addedComponent(MarkupContainer.java:978)
     at org.apache.wicket.MarkupContainer.add(MarkupContainer.java:168)
     at
 org.apache.wicket.examples.WicketExamplePage.onInitialize(WicketExamplePage.java:67)
     at org.apache.wicket.Component.initialize(Component.java:970)
     at
 org.apache.wicket.MarkupContainer.initialize(MarkupContainer.java:992)
     at org.apache.wicket.Page.componentAdded(Page.java:1130)
     at
 org.apache.wicket.MarkupContainer.addedComponent(MarkupContainer.java:978)
     at org.apache.wicket.MarkupContainer.add(MarkupContainer.java:168)
     at
 org.apache.wicket.examples.WicketExamplePage.onInitialize(WicketExamplePage.java:67)
     at org.apache.wicket.Component.initialize(Component.java:970)
 

 In 
 org.apache.wicket.examples.WicketExamplePage.onInitialize(WicketExamplePage.java:67)
 I have add(header).

 My fix looks is:
 Index: wicket/src/main/java/org/apache/wicket/Component.java
 ===
 --- wicket/src/main/java/org/apache/wicket/Component.java (revision 978819)
 +++ wicket/src/main/java/org/apache/wicket/Component.java (working copy)
 @@ -967,8 +967,8 @@
  {
  if (!getFlag(FLAG_INITIALIZED))
  {
 + setFlag(FLAG_INITIALIZED, true);
  onInitialize();
 - setFlag(FLAG_INITIALIZED, true);
  }
  }

 Is this ok ?

 On Fri, Jul 23, 2010 at 5:45 PM, Igor Vaynberg 
 igor.vaynb...@gmail.comwrote:

 since this has turned into more of a vote should we take it to the
 user list so we get a wider range of responses?

 -igor

 On Fri, Jul 23, 2010 at 1:50 AM, Martijn Dashorst
 martijn.dasho...@gmail.com wrote:
  +1 for Johan's changes to make

Re: remove oninitialize/onconfigure from 1.4.x?

2010-07-24 Thread Igor Vaynberg 
On Sat, Jul 24, 2010 at 2:19 AM, Johan Compagner jcompag...@gmail.com wrote:
 I think that fix should be fine
 The thing i have is why does Page.componentAdded() really call initialize 
 again

its called because the page object itself needs to have onInitialize()
called on it.

-igor

 Will that not happen anyway?

 Also now i do see a but of weird initializing when you see the order..
 In MarkupContainer.addedComponent:

                if (page != null)
                {
                        component.initialize();
                }

                if (page != null)
                {
                        page.componentAdded(component);
                }


 so first we call component initialize. then page.componentAdded that
 will call initialize on the page.
 But isnt that a bit the wrong way around?

 If you are in the constructor of a page and you add a component.
 Then i think the component is called initialized on and
 page.componentAdded will then call initialize on itself
 But then the component is called initialized first before the page is
 initialized
 AND we are still in the constructor of the page so initialize is
 suddenly called on a page that is still constructing?
 (i have to test this a bit, just looking at the code quickly)

 i think we should have some logic that as long as the page is not
 initialized, component shouldnt also be initialized.
 And for a page the same thing as for a component should happen, only
 after construction the initialize is called.

 johan


 On Sat, Jul 24, 2010 at 11:05, Martin Grigorov mgrigo...@apache.org wrote:
 +1 for vote in users@

 I just found a problem while creating new wicket-example for the new request
 mappers:

 java.lang.StackOverflowError
  at
 org.apache.wicket.MarkupContainer.addedComponent(MarkupContainer.java:978)
     at org.apache.wicket.MarkupContainer.add(MarkupContainer.java:168)
     at
 org.apache.wicket.examples.WicketExamplePage.onInitialize(WicketExamplePage.java:67)
     at org.apache.wicket.Component.initialize(Component.java:970)
     at
 org.apache.wicket.MarkupContainer.initialize(MarkupContainer.java:992)
     at org.apache.wicket.Page.componentAdded(Page.java:1130)
     at
 org.apache.wicket.MarkupContainer.addedComponent(MarkupContainer.java:978)
     at org.apache.wicket.MarkupContainer.add(MarkupContainer.java:168)
     at
 org.apache.wicket.examples.WicketExamplePage.onInitialize(WicketExamplePage.java:67)
     at org.apache.wicket.Component.initialize(Component.java:970)
     at
 org.apache.wicket.MarkupContainer.initialize(MarkupContainer.java:992)
     at org.apache.wicket.Page.componentAdded(Page.java:1130)
     at
 org.apache.wicket.MarkupContainer.addedComponent(MarkupContainer.java:978)
     at org.apache.wicket.MarkupContainer.add(MarkupContainer.java:168)
     at
 org.apache.wicket.examples.WicketExamplePage.onInitialize(WicketExamplePage.java:67)
     at org.apache.wicket.Component.initialize(Component.java:970)
     at
 org.apache.wicket.MarkupContainer.initialize(MarkupContainer.java:992)
     at org.apache.wicket.Page.componentAdded(Page.java:1130)
     at
 org.apache.wicket.MarkupContainer.addedComponent(MarkupContainer.java:978)
     at org.apache.wicket.MarkupContainer.add(MarkupContainer.java:168)
     at
 org.apache.wicket.examples.WicketExamplePage.onInitialize(WicketExamplePage.java:67)
     at org.apache.wicket.Component.initialize(Component.java:970)
     at
 org.apache.wicket.MarkupContainer.initialize(MarkupContainer.java:992)
     at org.apache.wicket.Page.componentAdded(Page.java:1130)
     at
 org.apache.wicket.MarkupContainer.addedComponent(MarkupContainer.java:978)
     at org.apache.wicket.MarkupContainer.add(MarkupContainer.java:168)
     at
 org.apache.wicket.examples.WicketExamplePage.onInitialize(WicketExamplePage.java:67)
     at org.apache.wicket.Component.initialize(Component.java:970)
 

 In 
 org.apache.wicket.examples.WicketExamplePage.onInitialize(WicketExamplePage.java:67)
 I have add(header).

 My fix looks is:
 Index: wicket/src/main/java/org/apache/wicket/Component.java
 ===
 --- wicket/src/main/java/org/apache/wicket/Component.java (revision 978819)
 +++ wicket/src/main/java/org/apache/wicket/Component.java (working copy)
 @@ -967,8 +967,8 @@
  {
  if (!getFlag(FLAG_INITIALIZED))
  {
 + setFlag(FLAG_INITIALIZED, true);
  onInitialize();
 - setFlag(FLAG_INITIALIZED, true);
  }
  }

 Is this ok ?

 On Fri, Jul 23, 2010 at 5:45 PM, Igor Vaynberg 
 igor.vaynb...@gmail.comwrote:

 since this has turned into more of a vote should we take it to the
 user list so we get a wider range of responses?

 -igor

 On Fri, Jul 23, 2010 at 1:50 AM, Martijn Dashorst
 martijn.dasho...@gmail.com wrote:
  +1 for Johan's changes to make the surface area of the change smaller.
 
  I didn't find onInitialize and onConfigure in our code base as well.
 
  The benefits are evident. So that is +0 from me to keep them in.

Re: remove oninitialize/onconfigure from 1.4.x?

2010-07-24 Thread Igor Vaynberg 
recrete it in ComponentInitializationTest and fix it :)

-igor

On Sat, Jul 24, 2010 at 2:05 AM, Martin Grigorov mgrigo...@apache.org wrote:
 +1 for vote in users@

 I just found a problem while creating new wicket-example for the new request
 mappers:

 java.lang.StackOverflowError
  at
 org.apache.wicket.MarkupContainer.addedComponent(MarkupContainer.java:978)
     at org.apache.wicket.MarkupContainer.add(MarkupContainer.java:168)
     at
 org.apache.wicket.examples.WicketExamplePage.onInitialize(WicketExamplePage.java:67)
     at org.apache.wicket.Component.initialize(Component.java:970)
     at
 org.apache.wicket.MarkupContainer.initialize(MarkupContainer.java:992)
     at org.apache.wicket.Page.componentAdded(Page.java:1130)
     at
 org.apache.wicket.MarkupContainer.addedComponent(MarkupContainer.java:978)
     at org.apache.wicket.MarkupContainer.add(MarkupContainer.java:168)
     at
 org.apache.wicket.examples.WicketExamplePage.onInitialize(WicketExamplePage.java:67)
     at org.apache.wicket.Component.initialize(Component.java:970)
     at
 org.apache.wicket.MarkupContainer.initialize(MarkupContainer.java:992)
     at org.apache.wicket.Page.componentAdded(Page.java:1130)
     at
 org.apache.wicket.MarkupContainer.addedComponent(MarkupContainer.java:978)
     at org.apache.wicket.MarkupContainer.add(MarkupContainer.java:168)
     at
 org.apache.wicket.examples.WicketExamplePage.onInitialize(WicketExamplePage.java:67)
     at org.apache.wicket.Component.initialize(Component.java:970)
     at
 org.apache.wicket.MarkupContainer.initialize(MarkupContainer.java:992)
     at org.apache.wicket.Page.componentAdded(Page.java:1130)
     at
 org.apache.wicket.MarkupContainer.addedComponent(MarkupContainer.java:978)
     at org.apache.wicket.MarkupContainer.add(MarkupContainer.java:168)
     at
 org.apache.wicket.examples.WicketExamplePage.onInitialize(WicketExamplePage.java:67)
     at org.apache.wicket.Component.initialize(Component.java:970)
     at
 org.apache.wicket.MarkupContainer.initialize(MarkupContainer.java:992)
     at org.apache.wicket.Page.componentAdded(Page.java:1130)
     at
 org.apache.wicket.MarkupContainer.addedComponent(MarkupContainer.java:978)
     at org.apache.wicket.MarkupContainer.add(MarkupContainer.java:168)
     at
 org.apache.wicket.examples.WicketExamplePage.onInitialize(WicketExamplePage.java:67)
     at org.apache.wicket.Component.initialize(Component.java:970)
 

 In 
 org.apache.wicket.examples.WicketExamplePage.onInitialize(WicketExamplePage.java:67)
 I have add(header).

 My fix looks is:
 Index: wicket/src/main/java/org/apache/wicket/Component.java
 ===
 --- wicket/src/main/java/org/apache/wicket/Component.java (revision 978819)
 +++ wicket/src/main/java/org/apache/wicket/Component.java (working copy)
 @@ -967,8 +967,8 @@
  {
  if (!getFlag(FLAG_INITIALIZED))
  {
 + setFlag(FLAG_INITIALIZED, true);
  onInitialize();
 - setFlag(FLAG_INITIALIZED, true);
  }
  }

 Is this ok ?

 On Fri, Jul 23, 2010 at 5:45 PM, Igor Vaynberg igor.vaynb...@gmail.comwrote:

 since this has turned into more of a vote should we take it to the
 user list so we get a wider range of responses?

 -igor

 On Fri, Jul 23, 2010 at 1:50 AM, Martijn Dashorst
 martijn.dasho...@gmail.com wrote:
  +1 for Johan's changes to make the surface area of the change smaller.
 
  I didn't find onInitialize and onConfigure in our code base as well.
 
  The benefits are evident. So that is +0 from me to keep them in.
  Pushing them to only 1.5 ensures we get enough folks trying 1.5 though
  :)
 
  Martijn
 
  On Fri, Jul 23, 2010 at 10:38 AM, 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
 
 
 
 
 
  --
  Become a Wicket expert, learn from

Re: remove oninitialize/onconfigure from 1.4.x?

2010-07-23 Thread Johan Compagner 
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?

2010-07-23 Thread Martijn Dashorst 
+1 for Johan's changes to make the surface area of the change smaller.

I didn't find onInitialize and onConfigure in our code base as well.

The benefits are evident. So that is +0 from me to keep them in.
Pushing them to only 1.5 ensures we get enough folks trying 1.5 though
:)

Martijn

On Fri, Jul 23, 2010 at 10:38 AM, 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





-- 
Become a Wicket expert, learn from the best: http://wicketinaction.com
Apache Wicket 1.4 increases type safety for web applications
Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.4.8

Re: remove oninitialize/onconfigure from 1.4.x?

2010-07-23 Thread Martin Grigorov 
I'm also +1 to keep them in 1.4.
Addition of new code is not exactly backward incompatible change. The names
of the methods are common so the chance of clash is bigger but still there
is such
chance with any other addition.

On Fri, Jul 23, 2010 at 10:50 AM, Martijn Dashorst 
martijn.dasho...@gmail.com wrote:

 +1 for Johan's changes to make the surface area of the change smaller.

 I didn't find onInitialize and onConfigure in our code base as well.

 The benefits are evident. So that is +0 from me to keep them in.
 Pushing them to only 1.5 ensures we get enough folks trying 1.5 though
 :)

 Martijn

 On Fri, Jul 23, 2010 at 10:38 AM, 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
 
 



 --
 Become a Wicket expert, learn from the best: http://wicketinaction.com
 Apache Wicket 1.4 increases type safety for web applications
 Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.4.8

Re: remove oninitialize/onconfigure from 1.4.x?

2010-07-23 Thread Martijn Dashorst 
Which is why it is rather inadvisable. This way it is not a drop-in
release, which  we usually promise (unless a security issue or blocker
forces us to forego binary compatibility)

However, I do think that the benefit of having these methods available
now are significant.

Martijn

On Fri, Jul 23, 2010 at 12:21 PM, Martin Grigorov mgrigo...@apache.org wrote:
 I'm also +1 to keep them in 1.4.
 Addition of new code is not exactly backward incompatible change. The names
 of the methods are common so the chance of clash is bigger but still there
 is such
 chance with any other addition.

 On Fri, Jul 23, 2010 at 10:50 AM, Martijn Dashorst 
 martijn.dasho...@gmail.com wrote:

 +1 for Johan's changes to make the surface area of the change smaller.

 I didn't find onInitialize and onConfigure in our code base as well.

 The benefits are evident. So that is +0 from me to keep them in.
 Pushing them to only 1.5 ensures we get enough folks trying 1.5 though
 :)

 Martijn

 On Fri, Jul 23, 2010 at 10:38 AM, 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
 
 



 --
 Become a Wicket expert, learn from the best: http://wicketinaction.com
 Apache Wicket 1.4 increases type safety for web applications
 Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.4.8





-- 
Become a Wicket expert, learn from the best: http://wicketinaction.com
Apache Wicket 1.4 increases type safety for web applications
Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.4.8

Re: remove oninitialize/onconfigure from 1.4.x?

2010-07-23 Thread Pedro Santos 
Hi Johan, actually it is 2 overridable protected methods that can execute an
rule already implemented by some custom component.
I attached an test to via Jira site showing the possible problem.

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

On Fri, Jul 23, 2010 at 5:38 AM, Johan Compagner jcompag...@gmail.comwrote:

 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
 




-- 
Pedro Henrique Oliveira dos Santos

Re: remove oninitialize/onconfigure from 1.4.x?

2010-07-23 Thread Johan Compagner 
yes if you use the package org.apache.wicket!!!
But that is something i definitely dont see as a problem because you
shouldnt do that.
org.apache.wicket is the package of wicket itself (just like java.lang
is of java itself)

johan


On Fri, Jul 23, 2010 at 14:02, Pedro Santos pedros...@gmail.com wrote:
 Hi Johan, actually it is 2 overridable protected methods that can execute an
 rule already implemented by some custom component.
 I attached an test to via Jira site showing the possible problem.

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

 On Fri, Jul 23, 2010 at 5:38 AM, Johan Compagner jcompag...@gmail.comwrote:

 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
 




 --
 Pedro Henrique Oliveira dos Santos

Re: remove oninitialize/onconfigure from 1.4.x?

2010-07-23 Thread Pedro Santos 
Good point, I used an test case that was in the same package that the
component, what invalidate the test. But the described problem remains. I
attached in the Jira another test case, in another package...

On Fri, Jul 23, 2010 at 9:06 AM, Johan Compagner jcompag...@gmail.comwrote:

 yes if you use the package org.apache.wicket!!!
 But that is something i definitely dont see as a problem because you
 shouldnt do that.
 org.apache.wicket is the package of wicket itself (just like java.lang
 is of java itself)

 johan


 On Fri, Jul 23, 2010 at 14:02, Pedro Santos pedros...@gmail.com wrote:
  Hi Johan, actually it is 2 overridable protected methods that can execute
 an
  rule already implemented by some custom component.
  I attached an test to via Jira site showing the possible problem.
 
  https://issues.apache.org/jira/browse/WICKET-2960
 
  On Fri, Jul 23, 2010 at 5:38 AM, 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
  
 
 
 
 
  --
  Pedro Henrique Oliveira dos Santos
 




-- 
Pedro Henrique Oliveira dos Santos

Re: remove oninitialize/onconfigure from 1.4.x?

2010-07-23 Thread Johan Compagner 
And that test just tells us what we already know and that if they have
onInitialize() or onConfigure() that those are the problem.


On Fri, Jul 23, 2010 at 14:22, Pedro Santos pedros...@gmail.com wrote:
 Good point, I used an test case that was in the same package that the
 component, what invalidate the test. But the described problem remains. I
 attached in the Jira another test case, in another package...

 On Fri, Jul 23, 2010 at 9:06 AM, Johan Compagner jcompag...@gmail.comwrote:

 yes if you use the package org.apache.wicket!!!
 But that is something i definitely dont see as a problem because you
 shouldnt do that.
 org.apache.wicket is the package of wicket itself (just like java.lang
 is of java itself)

 johan


 On Fri, Jul 23, 2010 at 14:02, Pedro Santos pedros...@gmail.com wrote:
  Hi Johan, actually it is 2 overridable protected methods that can execute
 an
  rule already implemented by some custom component.
  I attached an test to via Jira site showing the possible problem.
 
  https://issues.apache.org/jira/browse/WICKET-2960
 
  On Fri, Jul 23, 2010 at 5:38 AM, 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
  
 
 
 
 
  --
  Pedro Henrique Oliveira dos Santos
 




 --
 Pedro Henrique Oliveira dos Santos

Re: remove oninitialize/onconfigure from 1.4.x?

2010-07-23 Thread 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?

2010-07-23 Thread Martin Grigorov 
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: remove oninitialize/onconfigure from 1.4.x?

2010-07-23 Thread 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: remove oninitialize/onconfigure from 1.4.x?

2010-07-23 Thread Igor Vaynberg 
since this has turned into more of a vote should we take it to the
user list so we get a wider range of responses?

-igor

On Fri, Jul 23, 2010 at 1:50 AM, Martijn Dashorst
martijn.dasho...@gmail.com wrote:
 +1 for Johan's changes to make the surface area of the change smaller.

 I didn't find onInitialize and onConfigure in our code base as well.

 The benefits are evident. So that is +0 from me to keep them in.
 Pushing them to only 1.5 ensures we get enough folks trying 1.5 though
 :)

 Martijn

 On Fri, Jul 23, 2010 at 10:38 AM, 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





 --
 Become a Wicket expert, learn from the best: http://wicketinaction.com
 Apache Wicket 1.4 increases type safety for web applications
 Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.4.8

remove oninitialize/onconfigure from 1.4.x?

2010-07-22 Thread Igor Vaynberg 
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