Re: Oracle plans to dump risky Java serialization | InfoWorld
interesting ..
Suddenly java gets passed by reference instead of value?
things like: (sounds dark magic to me ;) )
@Serializer
public pattern Range(int lo, int hi) {
lo = this.lo;
hi = this.hi;
}
On Wed, 12 Jun 2019 at 12:47, Martin Grigorov wrote:
> Current state:
> http://cr.openjdk.java.net/~briangoetz/amber/serialization.html
>
> On Sat, May 26, 2018 at 1:39 PM Martijn Dashorst <
> martijn.dasho...@gmail.com>
> wrote:
>
> >
> >
> >
> https://www.infoworld.com/article/3275924/java/oracle-plans-to-dump-risky-java-serialization.amp.html?__twitter_impression=true
> >
> > Oracle plans to dump risky Java serialization
> > A “horrible mistake” from 1997, the Java object serialization capability
> > for encoding objects has serious security issues
> >
> > Paul Krill
> >
> > Getty Images
> > Oracle plans to drop from Java its serialization feature that has been a
> > thorn in the side when it comes to security. Also known as Java object
> > serialization, the feature is used for encoding objects into streams of
> > bytes. Used for lightweight persistence and communication via sockets or
> > Java RMI, serialization also supports the reconstruction of an object
> graph
> > from a stream.
> >
> > Removing serialization is a long-term goal and is part of Project Amber,
> > which is focused on productivity-oriented Java language features, says
> Mark
> > Reinhold, chief architect of the Java platform group at Oracle.
> >
> > To replace the current serialization technology, a small serialization
> > framework would be placed in the platform once records, the Java version
> of
> > data classes, are supported. The framework could support a graph of
> > records, and developers could plug in a serialization engine of their
> > choice, supporting formats such as JSON or XML, enabling serialization of
> > records in a safe way. But Reinhold cannot yet say which release of Java
> > will have the records capability.
> >
> > Serialization was a “horrible mistake” made in 1997, Reinhold says. He
> > estimates that at least a third—maybe even half—of Java vulnerabilities
> > have involved serialization. Serialization overall is brittle but holds
> the
> > appeal of being easy to use in simple use cases, Reinhold says.
> >
> > Recently, a filtering capability was added to Java so if serialization is
> > being used on a network and untrusted serialization data streams must be
> > accepted, there is a way to filter which classes can be mentioned, to
> > provide a defense mechanism against serialization’s security weaknesses.
> > Reinhold says Oracle has received many reports are received about
> > application servers running on the network with unprotected ports taking
> > serialization streams, which is why the filtering capability was
> developed.
> >
> >
>
Re: IntHashMap is transient
Ehh serialisation is done in read and writeobject methods, all the stuff should be created there (readObject) The entry array is not meant to be serialized by itself. At first sight it seem to be correct, the sizes are serialized and then an int + object pair is done. And the read creates the table and reads the pairs back in. Op 17 nov. 2014 20:20 schreef Sven Meier s...@meiers.net: Hi Martin, I don't know why the fields are transient, Johan probably never expected the map to be serialized. Sven On 11/17/2014 04:57 PM, Martin Grigorov wrote: Hi, https://issues.apache.org/jira/browse/WICKET-5751 and https://issues.apache.org/jira/browse/WICKET-5584 show a problem with the deserialization of IntHashMap https://github.com/apache/wicket/blob/master/wicket- util/src/main/java/org/apache/wicket/util/collections/IntHashMap.java . Many of its fields are transient for some reason and this leads to NullPointerExceptions when instances of IntHashMap are used after deserialization. Anyone have idea why these fields are transient ? Martin Grigorov Wicket Training and Consulting https://twitter.com/mtgrigorov
Re: JQuery 1.10.1 dependency also breaks many applications
Ah we are taking here about the removal of the deprecated api not the code for other browsers. That was 2.0 yes. Couldn't look it up that easy on vacation.. But then I guess we need to stick to 1.8.x On 3 Jul 2013 12:05, Martijn Dashorst martijn.dasho...@gmail.com wrote: On Wed, Jul 3, 2013 at 11:47 AM, Johan Compagner jcompag...@gmail.com wrote: Why not just go to the latest 1.9.x? I thought that was .10 but without all the removed api? 1.9 has removed the api. Martijn On 3 Jul 2013 11:13, Martijn Dashorst martijn.dasho...@gmail.com wrote: While I typically agree that using the latest stable versions of things is a good thing™, in this case the almighty gods that maintain jquery have decided to move deprecated APIs from versions prior to 1.9 into a migration plugin. In my opinion they did a major booboo to say the least, and more accurately they fucked up majorly–YOU DON'T REMOVE PUBLIC API IN A MINOR RELEASE! Upgrading to wicket 6.9 breaks all our applications that use any jquery plugin that was developed in the last decade. I think we should not have forcefully upgraded jquery to 1.10.1 in 6.9 (we should've caught that though), unless... we forcefully include the jquery migration plugin [1] as well in 6.9 (also available for jquery 2.x). We can make it so that the migration plugin is enabled by default for wicket 6.x applications, and in 7.x by default disabled. As we are already considering 6.9.1, I think we should fix this issue as well in 6.9.1. [ ] Release 6.9.1 with downgrade to jquery 1.8.3 [ ] Release 6.9.1 with jquery 1.10.1 and jquery migration plugin [ ] Release 6.9.1 with downgrade to jquery 1.8.3, 6.10.0 with jquery 1.10.1 and migration plugin [ ] Don't fix jquery issues WDYT? Martijn [1] http://jquery.com/upgrade-guide/1.9/#jquery-migrate-plugin -- Become a Wicket expert, learn from the best: http://wicketinaction.com -- Become a Wicket expert, learn from the best: http://wicketinaction.com
Re: Eclipse settings files
those files are needed, at least to get a consistent formatting behavior across all developers. I would say just commit those files. Thats the whole point of the .settings dir in eclipse.. (else don't specify anything at the project level) On 14 January 2013 13:27, Emond Papegaaij emond.papega...@topicus.nlwrote: I just accidently pushed the changes to these files, so I hope noone objects :) If it's not ok, I've no problem with reverting these 2 commits. Emond On Monday 14 January 2013 09:02:47 Emond Papegaaij wrote: Hi all, The Eclipse settings files keep causing trouble for me. I've recently switched from the maven-eclipse-plugin to M2e. The first is deprecated and the latter has become much more stable lately and provides a much better integration of Maven in Eclipse. However, M2e changes the org.eclipse.jdt.core.prefs files in all projects and adds quite a few new files. These changed files make it impossible to rebase without stashing them first, which in turn requires me to close Eclipse. My question is: what should we do with these settings files? In my opinion they do not belong in the source, they should be added when importing the projects and ignored by git. However, M2e does not (yet?) support importing eclipse settings (it is possible with this plugin: https://github.com/papegaaij/m2e-settings, but that requires manually adding a plugin to Eclipse). So for now, I propose to upgrade the core setting files to Eclipse Juno and add .settings to .gitignore to ignore all other files. Is that ok, or does anyone have a better solution? Best regards, Emond
Re: Releasing in a semver world (= 6.x)
I am interested in your article.. How else to really do it then cherry picking.. but I guess h that also depends where you do you're good first? I always start at their lowest version I want to fix it and forward port it, almost never do back ports Op 10 sep. 2012 19:33 schreef Carl-Eric Menzel cmen...@wicketbuch.de het volgende: +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
Re: [VOTE] Release Wicket 1.4.21
+1 On 29 August 2012 15:41, Carl-Eric Menzel cmen...@wicketbuch.de wrote: 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: Maven hate (was Re: [VOTE] Release wicket 6.0.0-beta2)
While my hatred for Maven runs deep, I have yet to find a solution that works better or is more appealing. Martijn really?? runs deep? for martijn? i just can't believe that!
Re: Move to servlet-api 3.0 for Wicket 6
Explain to me then what Wicket it self really needs from the new API? So what are we going to change? On Apr 13, 2012 2:32 PM, Emond Papegaaij emond.papega...@topicus.nl wrote: Hi all, It was already mentioned by Martijn some time ago as a suggestion for the roadmap for Wicket 6, but it was never decided. The question is: should we move to servlet-api 3.0 or stay at 2.5. Servlet 3.0 has been around for over 2 years now and is supported by most (all?) servlet containers. It allows us to use things like the new annotations and asynchronous servlets. I'm +1 for moving to servlet 3.0 and already have some work done on the sandbox/atmosphere branch to get it working. Best regards, Emond
Re: wicket 6.0 and automatic model detachment
i think it would be fine to have something like this, and enabled by default but only to have an option to turn it off On Sat, Apr 7, 2012 at 22:30, Igor Vaynberg igor.vaynb...@gmail.com wrote: -1 on adding it if its not enabled by default. its a trivial class thats only about 40-50 lines of real code. adding it into extensions and not using it will just add to code rot because i doubt many people will go out looking for something like this since most of them wont even know that its possible to do this. -igor On Fri, Apr 6, 2012 at 11:28 PM, Sven Meier s...@meiers.net wrote: The listener won't be set in IFrameworkSettings by default, right? IMHO it's better located in extensions then. Sven On 04/07/2012 01:37 AM, James Carman wrote: Add the listener to core and if folks want to use it they can. You could have a component instantiation listener add the detach listener to the components. Another option would be an aspect. On Apr 6, 2012 12:43 PM, Igor Vaynbergigor.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: Decommission the wicketstuff.org server
fine by me, i am not sure why it does that, it seems to me that the script that tests if the server is up and running is to aggressive or something. Maybe point wicketstuff.org to wicket-library.com? On Mon, Mar 26, 2012 at 10:51, Martijn Dashorst martijn.dasho...@gmail.comwrote: All, We probably can (and should) decommission the wicketstuff server. It has served its purpose, and we should move the links to examples to wicket-library.com or to wicket-examples.herokuapp.com or something similar. Having a server that provides 503 or 500 pages most of the time does not give good confidence in our framework and our abilities to write software. As for the remaining content: I think the only part that is used now is the index page, which provides a 503 page at the time of writing this message. I propose to move the static website part to github.com Martijn -- Become a Wicket expert, learn from the best: http://wicketinaction.com
Re: [Vote] Release Apache Wicket 6.0.0-beta1
+1 On Mar 23, 2012 1:34 PM, Martin Grigorov mgrigo...@apache.org wrote: This vote is to release wicket 6.0.0-beta1. This is the first release of 6.x branch and its purpose is to get more feedback from the community. There are no more planned changes in the API but if you find something that can be made better now is the time to discuss it! Branch http://git-wip-us.apache.org/repos/asf/wicket/?p=wicket.git;a=shortlog;h=refs/heads/build/wicket-6.0.0-beta1 Artifacts http://people.apache.org/~mgrigorov/wicket-6.0.0-beta1/dist/ Maven repo https://repository.apache.org/content/repositories/orgapachewicket-105/ Changelog https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310561version=12315431 This vote ends Monday, March 26th at 03:00pm (GMT+2) Please test the release and offer your vote. The Wicket team!
Re: [vote] release wicket 1.4.20
+1 On Mar 7, 2012 5:47 PM, Igor Vaynberg igor.vaynb...@gmail.com wrote: This vote is to release wicket 1.4.20 Branch http://git-wip-us.apache.org/repos/asf/wicket/?p=wicket.git;a=shortlog;h=refs/heads/build/wicket-1.4.20 Artifacts http://people.apache.org/~ivaynberg/wicket-1.4.20/dist/ Maven repo https://repository.apache.org/content/repositories/orgapachewicket-065/ Changelog https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=truejqlQuery=fixVersion+%3D+%221.4.20%22+AND+project+%3D+WICKET This vote ends Saturday, March 10th at 9:00am (GMT-8) Please test the release and offer your vote. The Wicket team!
Re: Wicket 6: Java 6 or Java 7?
Stick for now to Java 6 or does somebody really has good reason (api or feature that he wants to use) to go to Java 7? I think java 7 almost brought nothing, the all postponed the nice stuff to Java 8 (which is postponed to next year i believe) i do think that the eol of java 6 is quite fast, i don't think java 7 is used a lot at all, i think even the latest ubuntu that i installed yesterday does still by default get java 6? on the mac its also still java 6 right? But i guess for November this could all change, a bit offtopic, but i like to rant: i am currently using java 7u4 and i am quite annoyed by this bug; http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7145592 so a git repo over https with self signed certificates is not going to work for EGit . johan On Thu, Feb 16, 2012 at 17:06, Martijn Dashorst martijn.dasho...@gmail.comwrote: With Oracle stopping support for Java 6 this year [1], should we target Java 7 instead in Wicket 6? Or leave that for Wicket 7? I'm for keeping Java 6 as our current platform for Wicket 6 (so we don't add to the confusion with numbering our releases). Wicket 7 can then be our Java 7 release, and Wicket 8 our Java 8 release :). Intermitted we can release 6.1 and such in accordance with semver and provide new functionality in those .y releases. Martijn, tossing this in front of the wolves :) [1] https://blogs.oracle.com/henrik/entry/updated_java_6_eol_date
Re: modal dialog and nesting of forms.
yes i just read that in a jira issue :) but in my example it doesn't ... will check it On Thu, Feb 16, 2012 at 20:20, Igor Vaynberg igor.vaynb...@gmail.comwrote: the whole idea of putting the modal into a wicket form is that forms inside the modal should change their form tags to divs because they see they are inside another form... -igor On Thu, Feb 16, 2012 at 11:16 AM, Johan Compagner jcompag...@gmail.com wrote: here: http://wicket.apache.org/apidocs/1.5/org/apache/wicket/extensions/ajax/markup/html/modal/ModalWindow.html we say If you want to use form in modal window component make sure that you put the modal window itself in another form (nesting forms is legal in Wicket) and that the form on modal window is submitted before the window get closed. problem is that this is illegal in the browser. And chrome some if i push through ajax new content in the modal dialog that has that form completely removes the form from the resulting component tree.. I guess this is because the modal dialog generates a form tag itself, and then also a form tag is generated in the content of the modal dialog itself and chrome just filters that out? Weird thing is that chrome doesn't do that when you do a full page refresh... johan
Re: modal dialog and nesting of forms.
ok for a form inside a modal dialog
you need to override:
/**
* @see org.apache.wicket.markup.html.form.Form#isRootForm()
*/
@Override
public boolean isRootForm()
{
return false;
}
because the default behavior will ofcourse not find any other form because
the modal dialog form is just in javascript/html, its not a wicket
component..
On Thu, Feb 16, 2012 at 20:22, Johan Compagner jcompag...@gmail.com wrote:
yes i just read that in a jira issue :)
but in my example it doesn't ...
will check it
On Thu, Feb 16, 2012 at 20:20, Igor Vaynberg igor.vaynb...@gmail.comwrote:
the whole idea of putting the modal into a wicket form is that forms
inside the modal should change their form tags to divs because they
see they are inside another form...
-igor
On Thu, Feb 16, 2012 at 11:16 AM, Johan Compagner jcompag...@gmail.com
wrote:
here:
http://wicket.apache.org/apidocs/1.5/org/apache/wicket/extensions/ajax/markup/html/modal/ModalWindow.html
we say
If you want to use form in modal window component make sure that you
put
the modal window itself in another form (nesting forms is legal in
Wicket)
and that the form on modal window is submitted before the window get
closed.
problem is that this is illegal in the browser.
And chrome some if i push through ajax new content in the modal dialog
that
has that form
completely removes the form from the resulting component tree..
I guess this is because the modal dialog generates a form tag itself,
and
then also a form tag is generated in the content of the modal dialog
itself
and chrome just filters that out?
Weird thing is that chrome doesn't do that when you do a full page
refresh...
johan
Re: modal dialog and nesting of forms.
but the modal dialog iself is not in a form..
there are only 2 forms in my example
the one that the modal dialog generates in js code
and the one inside the panel that i show in the modal dialog
But it is fixed by overriding that isRootForm() and returning false myself
then it works just fine
On Thu, Feb 16, 2012 at 20:52, Igor Vaynberg igor.vaynb...@gmail.comwrote:
the modal dialog form is, but since the panel is rendered inside
modal's parent initially the wicket form inside the modal should see
the wicket form that the modal itself is in...
the rendered hierarchy should be like this
form - wicket form
modal window
content panel
div - wicket form inside the modal rendered as div instead of form
now when modal is opened the content panel is reparented in dom
body
form - dom form created by modal js
content panel
div - wicket form inside the modal's content
-igor
On Thu, Feb 16, 2012 at 11:36 AM, Johan Compagner jcompag...@gmail.com
wrote:
ok for a form inside a modal dialog
you need to override:
/**
* @see org.apache.wicket.markup.html.form.Form#isRootForm()
*/
@Override
public boolean isRootForm()
{
return false;
}
because the default behavior will ofcourse not find any other form
because
the modal dialog form is just in javascript/html, its not a wicket
component..
On Thu, Feb 16, 2012 at 20:22, Johan Compagner jcompag...@gmail.com
wrote:
yes i just read that in a jira issue :)
but in my example it doesn't ...
will check it
On Thu, Feb 16, 2012 at 20:20, Igor Vaynberg igor.vaynb...@gmail.com
wrote:
the whole idea of putting the modal into a wicket form is that forms
inside the modal should change their form tags to divs because they
see they are inside another form...
-igor
On Thu, Feb 16, 2012 at 11:16 AM, Johan Compagner
jcompag...@gmail.com
wrote:
here:
http://wicket.apache.org/apidocs/1.5/org/apache/wicket/extensions/ajax/markup/html/modal/ModalWindow.html
we say
If you want to use form in modal window component make sure that you
put
the modal window itself in another form (nesting forms is legal in
Wicket)
and that the form on modal window is submitted before the window get
closed.
problem is that this is illegal in the browser.
And chrome some if i push through ajax new content in the modal
dialog
that
has that form
completely removes the form from the resulting component tree..
I guess this is because the modal dialog generates a form tag itself,
and
then also a form tag is generated in the content of the modal dialog
itself
and chrome just filters that out?
Weird thing is that chrome doesn't do that when you do a full page
refresh...
johan
Re: modal dialog and nesting of forms.
its way better to say that you should override that method and return
false..
because now you have to already know that you will show forms in a dialog
and place a form on some page..
What if you just have a modal window that you reuse all over the place in
many pages
then you have to add a form? Why doesn't wicket do that him self then
inside the modal window component
now it is also not always that nice, now the panel must know that it is
shown in a modal window and override that method
i am just thinking can't we make that isRootForm smarter that it also test
if it is inside a modal window..
On Thu, Feb 16, 2012 at 20:58, Igor Vaynberg igor.vaynb...@gmail.comwrote:
thats why the javadoc says to put the modal window component inside a
wicket form...
-igor
On Thu, Feb 16, 2012 at 11:55 AM, Johan Compagner jcompag...@gmail.com
wrote:
but the modal dialog iself is not in a form..
there are only 2 forms in my example
the one that the modal dialog generates in js code
and the one inside the panel that i show in the modal dialog
But it is fixed by overriding that isRootForm() and returning false
myself
then it works just fine
On Thu, Feb 16, 2012 at 20:52, Igor Vaynberg igor.vaynb...@gmail.com
wrote:
the modal dialog form is, but since the panel is rendered inside
modal's parent initially the wicket form inside the modal should see
the wicket form that the modal itself is in...
the rendered hierarchy should be like this
form - wicket form
modal window
content panel
div - wicket form inside the modal rendered as div instead of form
now when modal is opened the content panel is reparented in dom
body
form - dom form created by modal js
content panel
div - wicket form inside the modal's content
-igor
On Thu, Feb 16, 2012 at 11:36 AM, Johan Compagner jcompag...@gmail.com
wrote:
ok for a form inside a modal dialog
you need to override:
/**
* @see org.apache.wicket.markup.html.form.Form#isRootForm()
*/
@Override
public boolean isRootForm()
{
return false;
}
because the default behavior will ofcourse not find any other form
because
the modal dialog form is just in javascript/html, its not a wicket
component..
On Thu, Feb 16, 2012 at 20:22, Johan Compagner jcompag...@gmail.com
wrote:
yes i just read that in a jira issue :)
but in my example it doesn't ...
will check it
On Thu, Feb 16, 2012 at 20:20, Igor Vaynberg
igor.vaynb...@gmail.com
wrote:
the whole idea of putting the modal into a wicket form is that forms
inside the modal should change their form tags to divs because they
see they are inside another form...
-igor
On Thu, Feb 16, 2012 at 11:16 AM, Johan Compagner
jcompag...@gmail.com
wrote:
here:
http://wicket.apache.org/apidocs/1.5/org/apache/wicket/extensions/ajax/markup/html/modal/ModalWindow.html
we say
If you want to use form in modal window component make sure that
you
put
the modal window itself in another form (nesting forms is legal in
Wicket)
and that the form on modal window is submitted before the window
get
closed.
problem is that this is illegal in the browser.
And chrome some if i push through ajax new content in the modal
dialog
that
has that form
completely removes the form from the resulting component tree..
I guess this is because the modal dialog generates a form tag
itself,
and
then also a form tag is generated in the content of the modal
dialog
itself
and chrome just filters that out?
Weird thing is that chrome doesn't do that when you do a full page
refresh...
johan
Re: source/commits in jira
thx so it all depends first on: http://studio.plugins.atlassian.com/browse/JGIT-74 but then if we do the commit, how do we say to git that this is issue XXX ? So that the plugin knows that that commit is for that issue? I guess we we need to fill in certain things on commit we should start with that asap. On Fri, Feb 10, 2012 at 16:57, Martin Grigorov mgrigo...@apache.org wrote: https://issues.apache.org/jira/browse/INFRA-4157 On Fri, Feb 10, 2012 at 5:44 PM, Jeremy Thomerson jer...@wickettraining.com wrote: Feel free to email infrastruct...@apache.org to bring the subject up there. -- Jeremy Thomerson http://wickettraining.com *Need a CMS for Wicket? Use Brix! http://brixcms.org* On Fri, Feb 10, 2012 at 9:59 AM, Bertrand Guay-Paquet ber...@step.polymtl.ca wrote: Hi, I asked the same question on dec 22 and Igor replied : infra is working on this afaik. -igor So I guess they haven't finished yet! Bertrand On 10/02/2012 9:34 AM, Johan Compagner wrote: Hi, What broke now that we are over to git is the nice link between jira issues and the source code so this tab: https://issues.apache.org/**jira/browse/WICKET-1654?page=**com.atlassian. **jirafisheyeplugin:fisheye-**issuepanel#issue-tabs https://issues.apache.org/jira/browse/WICKET-1654?page=com.atlassian.jirafisheyeplugin:fisheye-issuepanel#issue-tabs (or that subversion tab which ofcourse will not work anymore) is there a solution for that for GIT? So that we can at least backtrack easy what is changed for a specific issue? -- Martin Grigorov jWeekend Training, Consulting, Development http://jWeekend.com
Re: source/commits in jira
can we somehow force that? Just like we did with svn that has that build in case:xxx support (in the commit dialog?) But i will place WICKET-XXX then in all my commits from now on On Fri, Feb 10, 2012 at 17:08, Martin Grigorov mgrigo...@apache.org wrote: On Fri, Feb 10, 2012 at 6:02 PM, Johan Compagner jcompag...@gmail.com wrote: thx so it all depends first on: http://studio.plugins.atlassian.com/browse/JGIT-74 but then if we do the commit, how do we say to git that this is issue XXX ? So that the plugin knows that that commit is for that issue? I guess we we need to fill in certain things on commit we should start with that asap. I think adding WICKET-XXX is enough. Currently I use git log --grep=WICKET-XXX to find all commits for a specific ticket. Since the history is locally it is quite fast. On Fri, Feb 10, 2012 at 16:57, Martin Grigorov mgrigo...@apache.org wrote: https://issues.apache.org/jira/browse/INFRA-4157 On Fri, Feb 10, 2012 at 5:44 PM, Jeremy Thomerson jer...@wickettraining.com wrote: Feel free to email infrastruct...@apache.org to bring the subject up there. -- Jeremy Thomerson http://wickettraining.com *Need a CMS for Wicket? Use Brix! http://brixcms.org* On Fri, Feb 10, 2012 at 9:59 AM, Bertrand Guay-Paquet ber...@step.polymtl.ca wrote: Hi, I asked the same question on dec 22 and Igor replied : infra is working on this afaik. -igor So I guess they haven't finished yet! Bertrand On 10/02/2012 9:34 AM, Johan Compagner wrote: Hi, What broke now that we are over to git is the nice link between jira issues and the source code so this tab: https://issues.apache.org/**jira/browse/WICKET-1654?page=**com.atlassian. **jirafisheyeplugin:fisheye-**issuepanel#issue-tabs https://issues.apache.org/jira/browse/WICKET-1654?page=com.atlassian.jirafisheyeplugin:fisheye-issuepanel#issue-tabs (or that subversion tab which ofcourse will not work anymore) is there a solution for that for GIT? So that we can at least backtrack easy what is changed for a specific issue? -- Martin Grigorov jWeekend Training, Consulting, Development http://jWeekend.com -- Martin Grigorov jWeekend Training, Consulting, Development http://jWeekend.com
Re: source/commits in jira
That could be tricky, because not all commits are always related to an issue i think.. But if the UI gives you the option (in eclipse at least for svn) then it is easer NOT to forget :) On Fri, Feb 10, 2012 at 17:12, Igor Vaynberg igor.vaynb...@gmail.comwrote: we can write a server hook to make sure the string is present i suppose. i am not sure if infra would like that or not... -igor On Fri, Feb 10, 2012 at 8:10 AM, Johan Compagner jcompag...@gmail.com wrote: can we somehow force that? Just like we did with svn that has that build in case:xxx support (in the commit dialog?) But i will place WICKET-XXX then in all my commits from now on On Fri, Feb 10, 2012 at 17:08, Martin Grigorov mgrigo...@apache.org wrote: On Fri, Feb 10, 2012 at 6:02 PM, Johan Compagner jcompag...@gmail.com wrote: thx so it all depends first on: http://studio.plugins.atlassian.com/browse/JGIT-74 but then if we do the commit, how do we say to git that this is issue XXX ? So that the plugin knows that that commit is for that issue? I guess we we need to fill in certain things on commit we should start with that asap. I think adding WICKET-XXX is enough. Currently I use git log --grep=WICKET-XXX to find all commits for a specific ticket. Since the history is locally it is quite fast. On Fri, Feb 10, 2012 at 16:57, Martin Grigorov mgrigo...@apache.org wrote: https://issues.apache.org/jira/browse/INFRA-4157 On Fri, Feb 10, 2012 at 5:44 PM, Jeremy Thomerson jer...@wickettraining.com wrote: Feel free to email infrastruct...@apache.org to bring the subject up there. -- Jeremy Thomerson http://wickettraining.com *Need a CMS for Wicket? Use Brix! http://brixcms.org* On Fri, Feb 10, 2012 at 9:59 AM, Bertrand Guay-Paquet ber...@step.polymtl.ca wrote: Hi, I asked the same question on dec 22 and Igor replied : infra is working on this afaik. -igor So I guess they haven't finished yet! Bertrand On 10/02/2012 9:34 AM, Johan Compagner wrote: Hi, What broke now that we are over to git is the nice link between jira issues and the source code so this tab: https://issues.apache.org/**jira/browse/WICKET-1654?page=**com.atlassian. **jirafisheyeplugin:fisheye-**issuepanel#issue-tabs https://issues.apache.org/jira/browse/WICKET-1654?page=com.atlassian.jirafisheyeplugin:fisheye-issuepanel#issue-tabs (or that subversion tab which ofcourse will not work anymore) is there a solution for that for GIT? So that we can at least backtrack easy what is changed for a specific issue? -- Martin Grigorov jWeekend Training, Consulting, Development http://jWeekend.com -- Martin Grigorov jWeekend Training, Consulting, Development http://jWeekend.com
Re: JS performance optimization in AjaxRequestTarget
or use the let statement.. but support in all browsers could be a bit
tricky ;)
shouild be javascript 1.7 (thats FF 2.0 from 2006) but i don't think its in
EcmaScript yet (looks like EcmaScript 6 gets it) and most other browsers
follow that and do currently Edition 5.x or something
On Thu, Feb 9, 2012 at 17:16, Frank van Lankvelt f...@a-eskwadraat.nlwrote:
On 8 feb. 2012, at 16:01, Emond Papegaaij emond.papega...@topicus.nl
wrote:
In Wicket 6, onDomReady and onLoad scripts are merged into one big
script in
the ResourceAggregator. This is to prevent many script tags, all with
$(document).ready(function(){...}) (or the wicket equivalent). This
merging is
only done for non-AJAX requests, to preserve the separate evaluates.
Removing
this check, will merge all evals into one.
One side note, the {}s are not added yet.
I'm not sure if this was implemented already, but javascript blocks do not
limit the scope of variables. See e.g. Crockford
http://javascript.crockford.com/code.html
The only way to limit scope is to use functions, according to this
document.
Cheers, Frank
Emond
On Wednesday 08 February 2012 16:54:17 Martin Grigorov wrote:
On Wed, Feb 8, 2012 at 4:50 PM, Emond Papegaaij
emond.papega...@topicus.nl wrote:
This is very easy to accomplish in 6.0. You only have to delete the
code
that keeps the scripts separate when AJAX :). I can fix this, if you
want?
I think we talk about different things.
I talk about Ajax response:
ajax-response
evaluate someJS1();/evaluate
evaluate someJS2();/evaluate
evaluate someJS3();/evaluate
component id=someIddivnew content/div
/ajax-request
Emond
On Wednesday 08 February 2012 16:44:14 Martin Grigorov wrote:
On Wed, Feb 8, 2012 at 4:33 PM, Bertrand Guay-Paquet
ber...@step.polymtl.ca wrote:
Hi,
Merging multiple evaluates together will change the scope of some
variables. The variables in the scope of an evaluate block would
carry
on
in the following evaluate blocks. This could however be mitigated by
wrapping each evaluate block in its own function.
True.
Wrapping them in {} should be enough to prevent this problem.
Bertrand
On 08/02/2012 8:24 AM, Martin Grigorov wrote:
Hi,
Do you imagine a use case in which severalevaluates in
ajax-response should be executed separately (one after another)
as
it is now ?
Eachevaluate (andpriority-evaluate) is executed in an eval() in
wicket-ajax.js. As we all know eval() is slow. As an optimization I
think we can merge allevaluates in one (at server side) and eval
them all together. The only drawback I see is that error reporting
will be worse because the exception message will say there is an
error in 'all JS in oneevaluate here'
Re: about webshere and relative url redirects: https://issues.apache.org/jira/browse/WICKET-3258
In wicket you can work around it (see the doc of WebResponse.sendRedirect()) I have currently no idea if you tune this behavior in websphere, i am just testing it a bit to see if it would possible work in websphere (but i encounter more problems that just this, for example getPathInfo() and getServletPath() and so on also behaves differently then in other containers. On Tue, Feb 7, 2012 at 09:15, Martin Grigorov mgrigo...@apache.org wrote: Hi Johan, I think you can reproduce the same behavior with simple Servlet and HttpServletResponse.sendRedirect(). If it still breaks then it is something to tune in WebSphere. If it works then there is something in Wicket. On Mon, Feb 6, 2012 at 6:06 PM, Johan Compagner jcompag...@gmail.com wrote: Websphere, i am currently testing our product in a war deployment with the latest wicket 1.4 code But i am still bumping against this with Websphere 8.0.2 was it really fixed? Do i need a setting somehow? It is really weird for example if this is the url http://jcompagner-pc:9080/servoy/servoy-webclient/solutions/solution/RadioTest we send ../../?wicketurl which is correct because we should get: http://jcompagner-pc:9080/servoy/servoy-webclient/?wicketurl but what i get: http://jcompagner-pc:9080/?wicketurl weird thing is if i do this: http://jcompagner-pc:9080/servoy/servoy-webclient/solutions/solution/RadioTest/a/b we send: ../../../../?wicketurl and then it works! But if i then play with it a bit http://jcompagner-pc:9080/servoy/servoy-webclient/solutions/solution/RadioTest/a/b and then force that this is send: ../../../?wicketurl i get: http://jcompagner-pc:9080/servoy/servoy-webclient/solutions/?wicketurl so that is still correct, there is 1 less removed.. But now i remove another one: ../../?wicketurl then i get this: http://jcompagner-pc:9080/?wicketurl ??? so now it seems to only use the servlet path/context again! if i kill another: ../?wicketurl http://jcompagner-pc:9080/servoy/?wicketurl so it seems that if the relative url has context/servletpath up dirs (so 1 or 2 ../) then it sees it as the context/servletpath thing and if it is more so i have 3 times ../ it sees it as the whole url!! Is Websphere trying to be to smart?? -- Martin Grigorov jWeekend Training, Consulting, Development http://jWeekend.com
about webshere and relative url redirects: https://issues.apache.org/jira/browse/WICKET-3258
Websphere, i am currently testing our product in a war deployment with the latest wicket 1.4 code But i am still bumping against this with Websphere 8.0.2 was it really fixed? Do i need a setting somehow? It is really weird for example if this is the url http://jcompagner-pc:9080/servoy/servoy-webclient/solutions/solution/RadioTest we send ../../?wicketurl which is correct because we should get: http://jcompagner-pc:9080/servoy/servoy-webclient/?wicketurl but what i get: http://jcompagner-pc:9080/?wicketurl weird thing is if i do this: http://jcompagner-pc:9080/servoy/servoy-webclient/solutions/solution/RadioTest/a/b we send: ../../../../?wicketurl and then it works! But if i then play with it a bit http://jcompagner-pc:9080/servoy/servoy-webclient/solutions/solution/RadioTest/a/b and then force that this is send: ../../../?wicketurl i get: http://jcompagner-pc:9080/servoy/servoy-webclient/solutions/?wicketurl so that is still correct, there is 1 less removed.. But now i remove another one: ../../?wicketurl then i get this: http://jcompagner-pc:9080/?wicketurl ??? so now it seems to only use the servlet path/context again! if i kill another: ../?wicketurl http://jcompagner-pc:9080/servoy/?wicketurl so it seems that if the relative url has context/servletpath up dirs (so 1 or 2 ../) then it sees it as the context/servletpath thing and if it is more so i have 3 times ../ it sees it as the whole url!! Is Websphere trying to be to smart??
Re: git and multiple workspaces with the 2 branches and 1 trunk (master?)
trying for quite some hours now to set it up nicely the solution described in that link below doesn't work for windows users, that just makes a copy. for windows users this script must be used: http://git.661346.n2.nabble.com/Fwd-git-git-new-workdir-for-Windows-9-td6479570.html (run it as an admin else the symbolic links won't be created) That seems to work, the only problem i currently facing is that when i do a synchronize in eclipse all files are marked as changed (which of course none of them are) Even a hard reset on the branch will not fix that. So still not really a workable nice solution for this problem :( johan On Wed, Jan 4, 2012 at 16:43, Emond Papegaaij emond.papega...@topicus.nlwrote: With git, switching between branches is very fast, but as you said, with Eclipse it's not. You can have a look at this: http://finik.net/2010/10/24/multiple-working-folders-with-single-git- repository/http://finik.net/2010/10/24/multiple-working-folders-with-single-git-%0Arepository/ Another solution is to use git remotes to link the clones using (local) remotes. You can add a remote using 'git remote add name path', after which you can push/fetch changes between your workspaces directly. Personally, I use this last approach, but that's mainly because I do not yet feel comfortable enough to play with git internals :) Emond On Wednesday 04 January 2012 16:25:32 Johan Compagner 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: git and multiple workspaces with the 2 branches and 1 trunk (master?)
what is the best way to set that ? or turn that off? i tried this http://stackoverflow.com/questions/1510798/trying-to-fix-line-endings-with-git-filter-branch-but-having-no-luck/1511273#1511273 but still many many outgoing changes. On Fri, Jan 6, 2012 at 14:09, Emond Papegaaij emond.papega...@topicus.nlwrote: core.autocrlf
Re: git and multiple workspaces with the 2 branches and 1 trunk (master?)
It seems to be fine now, when i do the cloning completely in eclipse with that property in the eclipse preferences set to false. On Fri, Jan 6, 2012 at 14:42, Emond Papegaaij emond.papega...@topicus.nlwrote: Well, you'd rather not rewrite the entire wicket history using filter-branch, or your co-committer (of which I am now one) will be very upset and angry. You can find information on git configuration at http://progit.org/book/ch7-1.html . It also contains a section about core.autocrlf. Just turn it off (unset to option or set it to false) and reset your repo. I'm not sure if this is done using 'git checkout .' or 'git reset --hard HEAD' after changing autocrlf. Cloning again also fixes it :) Emond On Friday 06 January 2012 14:26:38 Johan Compagner wrote: what is the best way to set that ? or turn that off? i tried this http://stackoverflow.com/questions/1510798/trying-to-fix-line-endings-with-g it-filter-branch-but-having-no-luck/1511273#1511273 but still many many outgoing changes. On Fri, Jan 6, 2012 at 14:09, Emond Papegaaij emond.papega...@topicus.nlwrote: core.autocrlf
Re: git and multiple workspaces with the 2 branches and 1 trunk (master?)
Ok, its getting clearer and clearer, The thing is what i want is that i can make make a change for 1.4, 1.5 and master/trunk And do that all locally Then push that to the remove at once. I guess what i just need to do for that is pull 1 git repo from remote, Get there the 3 branches at onces, that is inside a dir: \wicket_trunk\ (.git) and that is the also my wicket_trunk workspace and master is checked out then go to the wicket_15 workspace clone my local wicket_trunk to that workspace and checkout wicket_15. go to the wicket_14 workspace clone again the wicket_trunk to that workspace and checkout wicket_14. then when i make a change first in 1.4 workspace, i push that to 'remote' which is still local (the trunk repo) then i go to 1.5 workspace, i first do a pull from trunk, merge the changes that i got from 1.4 commit/push that and then i just do an merge in the 1.6/trunk/master repo. then everything is merged and i have in my 1.6/trunk repo all the changes over the 3 branches and i push that to the remove wicket at onces johan On Fri, Jan 6, 2012 at 14:28, Renaud Bruyeron bruye...@fullsix.com wrote: 2012/1/4 Johan Compagner jcompag...@gmail.com: What is then the nicest way? Because must i then do a commit the local on 1.4 push that to the remote then go to 1.5 and pull it, then merge the 1.4 changes to 1.5, commit that (this could be slightly different because of some changes) push that again to remote, and then do that for trunk/master/1.6 all over again? You must unlearn what you have learned - Yoda :) I find that the hardest thing with git is to remove the mental blocks inherited from subversion's centralized model. Just clone twice in /home/jc/wicket5 and /home/jc/wicket6, check out the correct branch in each, then setup 2 eclipse workspaces (one each). Then add remote references to be able to push/pull between the two. Then the process is what you describe, except you do not need to go to the remote origin, you can just move code between your 2 clones via push/pull, and then merge back and forth: for example while in /home/jc/wicket5, you do git pull local6 to bring in the changes in the 6 branch, you can then do the merge/cherry locally) When you are done, you can push to the remote origin. Renaud
Re: git and multiple workspaces with the 2 branches and 1 trunk (master?)
the thing is i like the first approach if that one works, why? Because then i am forced to first merge it over all revisions before i can then push it upstream at once i never can push right to wicket if i just make a change in 1.4 or 1.5, i need to think and open 1.5 and or trunk first and do there my stuff The only thing is that merge doesn't work for me yet, i get an error: Merge of revisions 56ab23584fcb1c3949e69255078239c85dacea69, 6fec67349a165fb109d93497275ed73f3734f634 with base 4c482e88eb9f3a74fac01c0a127f1e6be0df59fb using strategy resolve resulted in: Failed. when i have pushed it from 1.4 to 1.5 and then i want to merge it so i select the project - team - merge (merge tool is disabled, anybody knows how to get that in eclipse and what that is?) or cherry-picking (rebase i guess) also doesn't work for me. On Fri, Jan 6, 2012 at 15:42, Bertrand Guay-Paquet ber...@step.polymtl.cawrote: From what I understand, your solution would work well. You would have: wicket-trunk remote = gitHub wicket_14 remote = wicket-trunk wicket_15 remote = wicket-trunk What Renaud and and Edmond described is instead: wicket-trunk remotes = [gitHub, wicket_14, wicket_15] wicket_14 remotes = [gitHub, wicket-trunk, wicket_15] wicket_15 remotes = [gitHub, wicket_14, wicket-trunk] With the second way, you can push a change directly from one of your working dir clones to all the others at once. See http://stackoverflow.com/**questions/5620525/git-pushing-** to-two-repos-in-one-commandhttp://stackoverflow.com/questions/5620525/git-pushing-to-two-repos-in-one-commandand http://stackoverflow.com/**questions/5785549/able-to-** push-to-all-git-remotes-with-**the-one-commandhttp://stackoverflow.com/questions/5785549/able-to-push-to-all-git-remotes-with-the-one-command . I too am new to git so I'd like to know if there are disadvantages to the second approach. Bertrand On 06/01/2012 9:11 AM, Johan Compagner wrote: Ok, its getting clearer and clearer, The thing is what i want is that i can make make a change for 1.4, 1.5 and master/trunk And do that all locally Then push that to the remove at once. I guess what i just need to do for that is pull 1 git repo from remote, Get there the 3 branches at onces, that is inside a dir: \wicket_trunk\ (.git) and that is the also my wicket_trunk workspace and master is checked out then go to the wicket_15 workspace clone my local wicket_trunk to that workspace and checkout wicket_15. go to the wicket_14 workspace clone again the wicket_trunk to that workspace and checkout wicket_14. then when i make a change first in 1.4 workspace, i push that to 'remote' which is still local (the trunk repo) then i go to 1.5 workspace, i first do a pull from trunk, merge the changes that i got from 1.4 commit/push that and then i just do an merge in the 1.6/trunk/master repo. then everything is merged and i have in my 1.6/trunk repo all the changes over the 3 branches and i push that to the remove wicket at onces johan On Fri, Jan 6, 2012 at 14:28, Renaud Bruyeronbruye...@fullsix.com wrote: 2012/1/4 Johan Compagnerjcompag...@gmail.com**: What is then the nicest way? Because must i then do a commit the local on 1.4 push that to the remote then go to 1.5 and pull it, then merge the 1.4 changes to 1.5, commit that (this could be slightly different because of some changes) push that again to remote, and then do that for trunk/master/1.6 all over again? You must unlearn what you have learned - Yoda :) I find that the hardest thing with git is to remove the mental blocks inherited from subversion's centralized model. Just clone twice in /home/jc/wicket5 and /home/jc/wicket6, check out the correct branch in each, then setup 2 eclipse workspaces (one each). Then add remote references to be able to push/pull between the two. Then the process is what you describe, except you do not need to go to the remote origin, you can just move code between your 2 clones via push/pull, and then merge back and forth: for example while in /home/jc/wicket5, you do git pull local6 to bring in the changes in the 6 branch, you can then do the merge/cherry locally) When you are done, you can push to the remote origin. Renaud
Re: git and multiple workspaces with the 2 branches and 1 trunk (master?)
hmm i HATE command line i almost never use that, and i am not planning to use it much now, i really think that is what an IDE is for! This is just going back to the dark ages of the 90's or something Tooling like this should just be next, next, finish in my eyes, quick and easy. We are already 12 years into this century! with svn what i did was all in the UI of eclipse commit a set of file that belong to each other for a specific fix/feature in branch X in Eclipse install/instance X then go to Eclipse instance Y that i already always have open, say Team-Merge a nice merge clients comes up, a few next next, select exactly which commit i want, finish and i am done... thats 1 commit command in Eclipse X, 1 Merge command and 1 Commit command in Eclipse Y and i am done, nothing more. I have currently also no idea if a push did really work for me for https://issues.apache.org/jira/browse/WICKET-4325 i pushed this as far as i now know to wicket1.4.x, wicket1.5.x and master (should i use master or trunk?) johan On Fri, Jan 6, 2012 at 16:11, Emond Papegaaij emond.papega...@topicus.nlwrote: I try not to use EGit for these things. It's not the most stable piece of software. Cherry-picking and rebasing are related but are 2 different things. cherry-picking is done to pick one or more commits from one branch and apply them on another. Rebasing is used to move your commits over different branches, reorder them, move other commits before your commits, etc. Rebasing is one of the most powerful features of git, but it also has a major drawback: it changes your commits. Therefore, you should never rebase commits that you have already pushed to a remote repository. To port a change from 1.5 to 6.0, a cherry-pick usually works fine for me: in 1.5.x: git commit -m my commit got to wicket 6: git fetch wicket-1.5 (fetches the commit i just did on wicket-1.5) git cherry-pick wicket-1.5/wicket-1.5.x Emond On Friday 06 January 2012 15:55:15 Johan Compagner wrote: the thing is i like the first approach if that one works, why? Because then i am forced to first merge it over all revisions before i can then push it upstream at once i never can push right to wicket if i just make a change in 1.4 or 1.5, i need to think and open 1.5 and or trunk first and do there my stuff The only thing is that merge doesn't work for me yet, i get an error: Merge of revisions 56ab23584fcb1c3949e69255078239c85dacea69, 6fec67349a165fb109d93497275ed73f3734f634 with base 4c482e88eb9f3a74fac01c0a127f1e6be0df59fb using strategy resolve resulted in: Failed. when i have pushed it from 1.4 to 1.5 and then i want to merge it so i select the project - team - merge (merge tool is disabled, anybody knows how to get that in eclipse and what that is?) or cherry-picking (rebase i guess) also doesn't work for me. On Fri, Jan 6, 2012 at 15:42, Bertrand Guay-Paquet ber...@step.polymtl.cawrote: From what I understand, your solution would work well. You would have: wicket-trunk remote = gitHub wicket_14 remote = wicket-trunk wicket_15 remote = wicket-trunk What Renaud and and Edmond described is instead: wicket-trunk remotes = [gitHub, wicket_14, wicket_15] wicket_14 remotes = [gitHub, wicket-trunk, wicket_15] wicket_15 remotes = [gitHub, wicket_14, wicket-trunk] With the second way, you can push a change directly from one of your working dir clones to all the others at once. See http://stackoverflow.com/**questions/5620525/git-pushing-** to-two-repos-in-one-command http://stackoverflow.com/questions/5620525/g it-pushing-to-two-repos-in-one-commandand http://stackoverflow.com/**questions/5785549/able-to-** push-to-all-git-remotes-with-**the-one-command http://stackoverflow.com/ questions/5785549/able-to-push-to-all-git-remotes-with-the-one-command . I too am new to git so I'd like to know if there are disadvantages to the second approach. Bertrand On 06/01/2012 9:11 AM, Johan Compagner wrote: Ok, its getting clearer and clearer, The thing is what i want is that i can make make a change for 1.4, 1.5 and master/trunk And do that all locally Then push that to the remove at once. I guess what i just need to do for that is pull 1 git repo from remote, Get there the 3 branches at onces, that is inside a dir: \wicket_trunk\ (.git) and that is the also my wicket_trunk workspace and master is checked out then go to the wicket_15 workspace clone my local wicket_trunk to that workspace and checkout wicket_15. go to the wicket_14 workspace clone again the wicket_trunk to that workspace and checkout wicket_14. then when i make a change first in 1.4 workspace, i push that to 'remote' which is still local (the trunk repo) then i go to 1.5 workspace, i first do a pull from trunk, merge the changes that i got from 1.4 commit/push
Re: git and multiple workspaces with the 2 branches and 1 trunk (master?)
i have a friend of mine that is also a long time eclipse users and he has now a few months a job where they have to use Intellij his qoute from a few days (after using it now for quite a while) ago: btw, intellij sucksnah, eclipse is way ahead so i guess thats a matter of taste.. The good thing is that Eclipse itself (all the core plugins) are moving to GIT, so that will boost the eclipse plugin a lot if they eat there own ... On Fri, Jan 6, 2012 at 16:26, Martin Grigorov mgrigo...@apache.org wrote: Recently I switched to Intellij IDEA because I think Eclipse doesn't evolve :-) and I'm quite happy I'm a command line user mostly but for first time I decided to give the UI a chance to deal with the SCM for me and so far I'm quite happy with IDEA's integration for Git.
git and multiple workspaces with the 2 branches and 1 trunk (master?)
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: git and multiple workspaces with the 2 branches and 1 trunk (master?)
Yes i don't care to much about the disk space But if i make a commit in to 1.4 that also want to merge over 1.5 and trunk What is then the nicest way? Because must i then do a commit the local on 1.4 push that to the remote then go to 1.5 and pull it, then merge the 1.4 changes to 1.5, commit that (this could be slightly different because of some changes) push that again to remote, and then do that for trunk/master/1.6 all over again? Of course this can all be different i am just starting to look at git, so i maybe don't see all the different handles.. But the above approach is quite a bit harder and way more steps (at least it looks that way to me now) then what i would do with svn.. (using the merge client shipped with subclipse) On Wed, Jan 4, 2012 at 16:40, Martijn Dashorst martijn.dasho...@gmail.comwrote: On Wed, Jan 4, 2012 at 4:25 PM, 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.. It is logical: it is no different than having 3 checkouts of SVN living on your hard disk. A git checkout with full history is probably the size of O(1) of a SVN checkout (especially for SVN 1.7). You can still use your normal flow just as you'd do with SVN. If you don't like having to wait for the full checkout coming from the apache server, you can easily just clone locally, and set the remote afterwards. You don't have to use the one folder for all branches paradigm, but you can. Or I can, or Igor can, or Emond can. With git we have a choice ourselves. WIth SVN not so. Martijn
Re: git and multiple workspaces with the 2 branches and 1 trunk (master?)
Git switching could be very vast But between 1.4 and 1.5 there are really project changes (like wicket-core and just wicket) So if i switch between them in eclipse, i constantly get all kind of compile warnings... And if i reflect that again on our own servoy product (if we would also go to git) this is really not doable, i have also there 3 to 4 active branches and there from branch to branch the number of projects are completely different! because in eclipse plugins you just create quite a lot of projects, so every new branch has a few more projects Then switching it is just quite annoying if you ask me, because you constantly have to get eclipse into sync. I will look at the multiply working folders option, that really looks be me the best way. On Wed, Jan 4, 2012 at 16:43, Emond Papegaaij emond.papega...@topicus.nlwrote: With git, switching between branches is very fast, but as you said, with Eclipse it's not. You can have a look at this: http://finik.net/2010/10/24/multiple-working-folders-with-single-git- repository/http://finik.net/2010/10/24/multiple-working-folders-with-single-git-%0Arepository/ Another solution is to use git remotes to link the clones using (local) remotes. You can add a remote using 'git remote add name path', after which you can push/fetch changes between your workspaces directly. Personally, I use this last approach, but that's mainly because I do not yet feel comfortable enough to play with git internals :) Emond On Wednesday 04 January 2012 16:25:32 Johan Compagner 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: Please welcome Emond Papegaaij as a committer for Wicket
Start coding! :-) On Dec 30, 2011 4:26 PM, Emond Papegaaij emond.papega...@topicus.nl wrote: Thank you all for the confidence you have in my work! I'm really proud to be a member of the Wicket team and am looking forward to get some real work done. I've already pushed some patches for a few tickets, broke most testcases and fixed them again, so it's looking good :) On Friday 30 December 2011 14:59:39 Martijn Dashorst wrote: I am pleased to announce that the Wicket PMC has voted Emond Papegaaij as our newest member. Please welcome him to our team! Welcome Emond! Enjoy the New Year with Wicket! Martijn
Re: Wicket source code moved to Git
hmm i use EGit but some how i always get not authorized if i try to push something I am quite sure the username/password is correct, but will recheck it, i use this url: https://jcompag...@git-wip-us.apache.org/repos/asf/wicket.git On Wed, Dec 21, 2011 at 19:26, Jeremy Thomerson jer...@wickettraining.comwrote: On Tue, Dec 20, 2011 at 11:46 PM, Jeremy Thomerson jer...@wickettraining.com wrote: On Tue, Dec 20, 2011 at 11:20 PM, Clint Checketts checke...@gmail.com wrote: Jeremy, Will Git development mimic the current subversion workflow, or will we see we see a more Git-ish way like 'git flow'? See- http://nvie.com/posts/a-successful-git-branching-model/ I think at least the core developers are already trying to adopt a more git-like work flow. Look at some of the ajax/JS stuff that happened on GH prior to being merged into SVN. I'm definitely in favor of a more Git-ish way of doing things. I realize that likely the answer is 'we don't know yet', so I'd like to get the conversation going. I'd suggest: give us through the weekend for the committers to get git (hehe pun) setup and in use, then let's start a separate discussion. I also say this because of a very large thread on infrastructure-dev right now [1] about the current git hook that requires all committers to have an @ apache.org email address, which means for me to pull from your GH repo, for instance, I'd need to rewrite the history some. I think that this requirement will go away (the message I linked to is the first with real weight that says it can go away), but whatever the outcome of that thread is will have a major impact on our git-flow. Involvement with that ongoing thread among other conversations has kept from from actually playing with our git repo. I hope the distraction will be gone soon. [1] http://markmail.org/message/jsnmxdzf5qkkrvwg FYI... here's an update that the $contributorEmail =~ /.*@apache.org/requirement is now gone. See [2] This should make it easier to integrate a standard git workflow where we can merge branches from various users. Of course, the committers still need to do our due diligence to ensure code provenance. [2] http://markmail.org/message/3v47l7747xntqreq -- Jeremy Thomerson http://wickettraining.com *Need a CMS for Wicket? Use Brix! http://brixcms.org*
Re: Proposal: Moving wicketstuff.org Jenkins instance to a linux server (I volunteer to manage it)
fine by me i do monitor it now and then, problem if it doesn't run is mostly some full disk problem that i then clean up On Fri, Oct 14, 2011 at 06:08, Jeremy Thomerson jer...@wickettraining.com wrote: On Thu, Oct 13, 2011 at 11:53 PM, Michael O'Cleirigh michael.ocleir...@rivulet.ca wrote: Hello, Jenkins currently runs at wicketstuff.org/hudson. The wicketstuff.org server is running FreeBSD which is not directly supported by Jenkins and so upgrading and installing related tooling becomes a burden on the server admins. Recently there has been intermittent instability that causes jenkins to become unavailable and prevents developers from being easily able to generate and test new snapshot releases. My proposal is that we take advantage of the Jenkins community support for Linux that includes auto-installers and binary packages and switch to running the wicketstuff.org Jenkins instance on a Linux box. I am volunteering to host this on a VPS I have and to take care of the server side admin. If this is acceptable I would suggest moving jenkins from wicketstuff.org/hudson to a DNS A name like ci.wicketstuff.org that could point at my server. Then depending on the load I might ask to have the wicketstuff.org server setup as a slave to sometimes assist in building the projects but not be the main access point for the developers. Once this is setup I would also be interested in letting others contribute slaves to help with the build. In the past when I noticed that the wicketstuff.org/hudson server was down I would setup a private Jenkins instance to take care of building the SNAPSHOT's because I didn't want to run it in public with the same anyone can signup privileges. To get around this issue I have written a Jenkins authentication/authorization plugin that will restrict access to only members of a named github organization (i.e. only github users that are a member of the wicketstuff organization can access and invoke builds. This will let us manage access entirely through Github. The only restriction on the plugin right now is that the users affiliation in the team needs to be publicized. Plugin Link: https://wiki.jenkins-ci.org/display/JENKINS/Github+OAuth+Plugin I've published the 0.6 version of this plugin which now supports a post commit hook from github to trigger builds (i.e. no more @hourly polling is required). The test instance is here: http://rivulet.ca:8080/ Anyone with commit access in github that is a public member of the any team in the wicketstuff project can login and have the trigger build permission. Regards, Mike I'm +1000 for letting you handle all this build stuff and host it on your server. Copying Johan directly because IIRC the server it is currently on is his and I want to make sure he sees it. Big hooray! for Mike and all his endless work on wicketstuff!! -- Jeremy Thomerson http://wickettraining.com Need a CMS for Wicket? Use Brix! http://brixcms.org
Re: [vote] release wicket 1.4.19
+1 code wise it runs fine for us. (was already on a snapshot with the latest stuff) On Wed, Oct 12, 2011 at 18:10, Igor Vaynberg igor.vaynb...@gmail.com wrote: This vote is to release wicket 1.4.19 Branch http://svn.apache.org/repos/asf/wicket/branches/wicket-1.4.19 Artifacts http://people.apache.org/~ivaynberg/wicket-1.4.19/dist/ Maven repo https://repository.apache.org/content/repositories/orgapachewicket-057/ Changelog https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310561version=12317570 This vote ends Saturday, October 15 at 9:00am (GMT-7) Please test the release and offer your vote. The Wicket team!
Re: [vote] Restructure Packaging for OSGi
For us personally i don't care, 1 could be done, we are not on 1.5 yet and if we do the package rename is easy to fix. But i agree with the rest that this is to big to do in such a late stage, and maybe also after that stage. Because for osgi the simppe fix is to make one big jar right? Thats really easy... I would think that solution could be for now even after 1.5 be the right solution. johan On Wed, Aug 17, 2011 at 19:22, Igor Vaynberg igor.vaynb...@gmail.com wrote: a lot of energy has gone into discussing and prototyping wicket+osgi in the past few days. it seems the biggest obstacle is that there are split packages between wicket-[core,request,util] jars. usually we wouldnt fix this now because we are in RCs and it requires moving pretty much all classes, for example all classes in core/o.a.w would have to move to core/o.a.w.core, which is roughly 99% of all classes in Wicket. the fix should be relatively easy, running fix imports on the project from an IDE would fix all user-code, but like i said, i do acknowledge it is pretty damn late in the game to do such a thing. the alternative, however, seems also rather nasty. we would have to shade (merge) util and request modules under core. we would also have to maintain a custom maven plugin, that would be part of our build, that can generate osgi manifests for the shaded jar. this would also mean we would have to support the said plugin for all possible versions of maven out there that people building wicket from source use. yet another alternative is to basically give the finger to the osgi community and do nothing. they can repackage the jar to meet their needs elsewhere, maybe in wicketstuff. i dont think this is really an option given how much of people's energy and time went into even discovering these options, but its here for completeness' sake. so here are our options: 1) fix the split package problem now with a big package-rename-refactor that will affect all existing code that depends on 1.5. 2) introduce a custom maven plugin to shade/manifest wicket-core. fix the split package problem in wicket.next. 3) leave osgi support out of 1.5 vote ends saturday 8/20 at 10:30am gmt-7. -igor
Re: Wicketstuff maven repository
why is that suddenly disabled i ask my self, that always did work.. On Thu, Jul 21, 2011 at 09:18, Martin Grigorov mgrigo...@apache.org wrote: 1.4-SNAPSHOT is still there but I cannot make Tomcat see it. How can I configure Tomcat to list the contents of a folder in webapps/maven if maven/ has no WEB-INF/web.xml inside ? I have never did something like this. On Thu, Jul 21, 2011 at 9:47 AM, Emond Papegaaij emond.papega...@topicus.nl wrote: I just got a message from someone who needs the wicket-security 1.3.2 release (org.apache.wicket.wicket-security), but the 1.4.x releases are also not available on central. On Thursday 21 July 2011 08:38:10 Martin Grigorov wrote: What exactly do you need ? Most of the stuff is now available in central repo. On Thu, Jul 21, 2011 at 9:31 AM, Emond Papegaaij emond.papega...@topicus.nl wrote: Hi all, It seems the wicketstuff.org maven repository (at http://wicketstuff.org/maven/repository) is offline. Is this intentional? Best regards, Emond -- Martin Grigorov jWeekend Training, Consulting, Development http://jWeekend.com
Re: Wicketstuff maven repository
enabled dir listing http://www.wicketstuff.org/maven/repository/ On Thu, Jul 21, 2011 at 09:21, Johan Compagner jcompag...@gmail.com wrote: why is that suddenly disabled i ask my self, that always did work.. On Thu, Jul 21, 2011 at 09:18, Martin Grigorov mgrigo...@apache.org wrote: 1.4-SNAPSHOT is still there but I cannot make Tomcat see it. How can I configure Tomcat to list the contents of a folder in webapps/maven if maven/ has no WEB-INF/web.xml inside ? I have never did something like this. On Thu, Jul 21, 2011 at 9:47 AM, Emond Papegaaij emond.papega...@topicus.nl wrote: I just got a message from someone who needs the wicket-security 1.3.2 release (org.apache.wicket.wicket-security), but the 1.4.x releases are also not available on central. On Thursday 21 July 2011 08:38:10 Martin Grigorov wrote: What exactly do you need ? Most of the stuff is now available in central repo. On Thu, Jul 21, 2011 at 9:31 AM, Emond Papegaaij emond.papega...@topicus.nl wrote: Hi all, It seems the wicketstuff.org maven repository (at http://wicketstuff.org/maven/repository) is offline. Is this intentional? Best regards, Emond -- Martin Grigorov jWeekend Training, Consulting, Development http://jWeekend.com
Re: Wicket and Java 7
For Wicket 1.6 we can move to JDK6 but this will be discussed later. Usage of JDK7 for frameworks is not very close. this is an understatement :) wicket and java 7... my guess? more then 4 years... But who knows if Oracle speeds it up (they say Java 8 next year..) also the upgrades are a little bit faster by the users them selfs? For example when will java 6 be out of support by Oracle? (what java 5 currently already is..)
Re: Wicket and Java 7
the nice thing is that the diamond notation for generics is working out of the box when you can target 1.7 your self in your app. Thats can be quite a bit lot less typing of characters in wicket apps. On Tue, Jul 5, 2011 at 14:57, Martin Grigorov mgrigo...@apache.org wrote: I'm saying only that JDK7 based solutions should be in a separate module and pluggable. If my application runs on JDK7 then I can replace the default functionalityX (based on JDK5/6) with the improved one (based on JDK7). On Tue, Jul 5, 2011 at 2:52 PM, Andrea Del Bene adelb...@ciseonweb.it wrote: Well, I wasn't expecting a rapid or easy adoption of JDK7, but I think that is useful starting to explore how to parallelize some of the stages of Wicket's rendering pipeline. This could lead to a strong performance gain in the future, with adoption of JDK7 or using a parallel programming library. You know that Wicket still uses JDK 1.5 (not even 1.6) because many users still use JDK1.5 and cannot upgrade to the newer. So any improvements based on JDK7 should be out of wicket-core. They can be plugged but the default impl should be 1.5 based. For example you can create ModificationWatcher based on NIO2 but it will in wicket-jdk7 module (or similar) or in wicketstuff project. For Wicket 1.6 we can move to JDK6 but this will be discussed later. Usage of JDK7 for frameworks is not very close. On Tue, Jul 5, 2011 at 2:11 PM, Bruno Borgesbruno.bor...@gmail.com wrote: Some internals of Wicket don't use collections. Take for instance ResourceNameIterator. But certainly there are some things that can be used, like the new File watching API. *Bruno Borges* www.brunoborges.com.br +55 21 76727099 On Tue, Jul 5, 2011 at 9:04 AM, Andrea Del Beneadelb...@ciseonweb.itwrote: I know it could sound a bit premature, but hasanyone starting to think how improve Wicket with the new JDK? I think that the new concurrency and collections API could help to speed up Wicket. Has anyone run some tests? -- Martin Grigorov jWeekend Training, Consulting, Development http://jWeekend.com
Re: [vote] release wicket 1.4.17
+1 release On Mon, Mar 28, 2011 at 10:10, Martin Grigorov mgrigo...@apache.org wrote: On behalf of Igor Vaynberg: This vote is to release wicket 1.4.17. This is a bugfix release on the 1.4.x (stable) branch. Branch: http://svn.apache.org/repos/asf/wicket/branches/wicket-1.4.17/ Artifacts: http://people.apache.org/~ivaynberg/wicket-1.4.17/dist Maven repo: https://repository.apache.org/content/repositories/orgapachewicket-045/ Changelog: https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310561version=12316219 This vote ends Thursday, March 31st at 1:00am (GMT-8) Please test the release and offer your vote. The Wicket team
Re: Removing Pagemap lock post 1.5?
Expected behavior: - request1: starts processing, locks pagemap - request2: comes in: tries to acquire lock - request2: waits for max N seconds (N being a small number, 1 or 2 seconds) - request2: sets kill switch for request1 - request1: first time in wicket managed code: throws Abort exception, does not commit page hierarchy to pagemap this step can be quite complex, because at what stage is that? Also long request are very likely not touching any wicket code but those are in queries and so on besides that we must make sure that the object hiearchy and so on is not suddenly in a wrong state. And there are cases that request 1 is still way more important then request 2 and request 2 may never just kill 1. (Request 2 is just a background polling thread of are there any changes) - request2: starts processing its request
Re: [vote] release wicket 1.4.16
+1 On Mon, Feb 21, 2011 at 05:33, Igor Vaynberg igor.vaynb...@gmail.com wrote: This vote is to release wicket 1.4.16. This is a bugfix release on the 1.4.x (stable) branch. Branch: http://svn.apache.org/repos/asf/wicket/branches/wicket-1.4.16/ Artifacts: http://people.apache.org/~ivaynberg/wicket-1.4.16/dist Maven repo: https://repository.apache.org/content/repositories/orgapachewicket-031/ Changelog: https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310561version=12316020 This vote ends Wednesday, February 23rd at 9:00am (GMT-8) Please test the release and offer your vote. -igor
Re: 1.4.16 - adding methods to IBehavior
why not just introduce that interface and the impl in component? So why also alter abstract behavior? Because that would mean that suddenly almost all the behaviors that are used are suddenly also IComponentConfigurationBehavior And 99.9% of them don't do anything. On Sat, Feb 19, 2011 at 04:17, Jeremy Thomerson jer...@wickettraining.com wrote: What does everyone think about the following patch [1] to add two methods to IBehavior? Obviously, it's not added directly to IBehavior since that would be a breaking API change. It's added to a sub-interface that can optionally be implemented by IBehaviors and is implemented by AbstractBehavior by default. It's for the purpose of allowing behaviors to contribute to things like the visibility and enabled status of a component, which they can't currently do in beforeRender because that happens during the render cycle, at which time such changes are not allowed. [1] - http://mysticpaste.com/view/8231 -- Jeremy Thomerson http://wickettraining.com *Need a CMS for Wicket? Use Brix! http://brixcms.org*
Re: Reducing JIRA spam
fine by me On Tue, Feb 8, 2011 at 11:58, Martijn Dashorst martijn.dasho...@gmail.com wrote: It appears that we can reduce the amount of spam JIRA sends to our commits list by telling it not to send notifications when the fix-in version is modified. I'd like that feature to be enabled... Martijn -- Become a Wicket expert, learn from the best: http://wicketinaction.com
Re: rename classes and methods from *Javascript* to *JavaScript*
+1 On Tue, Dec 7, 2010 at 20:55, Igor Vaynberg igor.vaynb...@gmail.com wrote: +1 to make it consistent, dont care which way its spelled. -igor On Tue, Dec 7, 2010 at 9:51 PM, Juergen Donnerstag juergen.donners...@gmail.com wrote: what shall we do with http://issues.apache.org/jira/browse/WICKET-715? If we want to change it / make it consistent, we should change it anytime soon -Juergen
Re: svn commit: r1031432 - /wicket/branches/wicket-1.4.x/wicket/src/main/java/org/apache/wicket/ajax/AjaxRequestTarget.java
This commits breaks all header contributions when the ajaxrequesttarget has more then 1 component that it must render and the component after the first one also wants to render something in the head.. i committed a fix: commit -m fix form previous commit: 1031432... C:/workspace_wicket14/wicket-1.4.x/wicket/src/main/java/org/apache/wicket/ajax/AjaxRequestTarget.java Sending C:/workspace_wicket14/wicket-1.4.x/wicket/src/main/java/org/apache/wicket/ajax/AjaxRequestTarget.java Transmitting file data ... Committed revision 1040980. so that the header is now only closed after all components are rendered. Don't we have any test that would cover this? That should have failed? So a test that renders 2 components in an ajax request and both contribute some css or js. johan On Fri, Nov 5, 2010 at 06:07, jrthomer...@apache.org wrote: Author: jrthomerson Date: Fri Nov 5 05:07:52 2010 New Revision: 1031432 URL: http://svn.apache.org/viewvc?rev=1031432view=rev Log: AjaxRequestTarget was not calling IHeaderResponse.close() after traversing hierarchy to renderhead on all appropriate iheadercontributors Modified: wicket/branches/wicket-1.4.x/wicket/src/main/java/org/apache/wicket/ajax/AjaxRequestTarget.java Modified: wicket/branches/wicket-1.4.x/wicket/src/main/java/org/apache/wicket/ajax/AjaxRequestTarget.java URL: http://svn.apache.org/viewvc/wicket/branches/wicket-1.4.x/wicket/src/main/java/org/apache/wicket/ajax/AjaxRequestTarget.java?rev=1031432r1=1031431r2=1031432view=diff == --- wicket/branches/wicket-1.4.x/wicket/src/main/java/org/apache/wicket/ajax/AjaxRequestTarget.java (original) +++ wicket/branches/wicket-1.4.x/wicket/src/main/java/org/apache/wicket/ajax/AjaxRequestTarget.java Fri Nov 5 05:07:52 2010 @@ -1143,6 +1143,7 @@ public class AjaxRequestTarget implement } }); } + header.getHeaderResponse().close(); // revert to old response
Re: svn commit: r1033843 - in /wicket/trunk/wicket/src: main/java/org/apache/wicket/markup/html/ main/java/org/apache/wicket/resource/ main/java/org/apache/wicket/resource/aggregation/ main/java/org/a
ok this test was then correct that it failed.. Ajax does have to push it to the client because it doesnt know if it is there yet or not that you only know because of the id script id=xxx that can be set i believe then at the client side it is checked if that id is there already For example if you have a main page with tabs and those tabs are switched through an ajax request then everything that is inside that tab needs to be render and also the js and css contributions.. It could be that those are the same as the previous tab.. But the second tab doesn't know that. I think that is all resolved at the client side in the browser, but i guess matej or igor knows that a bit better them me. But all the components that are added to the AjaxRequestTarget should contribute.. Not only the first one and Jeremy's commit broke that johan On Fri, Nov 12, 2010 at 00:57, Jeremy Thomerson jrthomer...@apache.org wrote: On Thu, Nov 11, 2010 at 6:02 PM, Jeremy Thomerson jrthomer...@apache.org wrote: On Thu, Nov 11, 2010 at 4:04 AM, Martin Grigorov mgrigo...@apache.org wrote: Notice that I touched AjaxHeaderContributionPage2_ajax_expected.html and removed expected javascript header contribution after Ajax request. I think this is the proper fix because this JS url is already contributed by normal (non-Ajax) page load and it should not be redelivered later by Ajax contributions. So, the strange thing is that what makes this fail is that close() is now called after the component hierarchy traversal. The fact that it was not being called before really seems like a bug. But, closing it stops this contribution from being rendered because it is rendered after the header response is closed (and is therefore skipped). So, I have a couple questions: First - is your statement above correct? If I add a css file in the page, and then contribute the same URL via AJAX, should it be added to the page a second time? You say no, but it appears that we've been testing to make sure that it is. I think there could be cases where it should - what if that URL returns dynamic css (js, etc) that has changed since the page was originally loaded? It could be JSON, for instance, that has changed. Second - there's some strange order of operations happening here that's causing this. I am about to walk out the door and haven't had a chance to fully investigate why this is happening. I wonder why AjaxHeaderContribution2 overrides renderHead(HtmlHeaderContainer container) rather than implementing the normal IHeaderContributor method. Anybody know off the top of their head? Jeremy
Re: svn commit: r1031432 - /wicket/branches/wicket-1.4.x/wicket/src/main/java/org/apache/wicket/ajax/AjaxRequestTarget.java
i just moved your all a bit up the call chain so no when it handles 1 component but when it handles all components, see my commit. On Wed, Dec 1, 2010 at 15:15, Jeremy Thomerson jer...@wickettraining.com wrote: I think it does. I haven't had the opportunity to look through the entire thread, but it looks like Johan has a fix. As long as the fix still includes calling close somewhere near the end of the request, it works for me. In that case, if there are VP objections, I'll plan on building a release to vote on in the next 48 hours. Thoughts? Jeremy Thomerson http://wickettraining.com -- sent from my smart phone, so please excuse spelling, formatting, or compiler errors On Dec 1, 2010 8:42 AM, Ernesto Reinaldo Barreiro reier...@gmail.com wrote: Thanks for the explanation. So, this makes 1.4.14 a really dangerous version to use:-( Does this merits rolling out a 1.4.15? Regards, Ernesto On Wed, Dec 1, 2010 at 2:26 PM, Johan Compagner jcompag...@gmail.com wrote: that really sounds ...
Re: [vote] change ibehavior from interface to abstract class in trunk
+1 On Wed, Nov 24, 2010 at 03:22, Igor Vaynberg igor.vaynb...@gmail.com wrote: the ibehavior interface has become somewhat cluttered and a lot of methods in it can have a nice default implementation that works for 99% of the usecases. there is no longer a point to having it as an interface. this vote is to - rename IBehavior to Behavior and make it an abstract class with stubs for every method - rename AbstractBehavior to BaseBehavior and deprecate it, it has accumulated some crud over the years the only thing we will lose is the ability to cleanly proxy a ibehavior and to use it as a mixin - i cant think of any usecases for either vote ends 7pm gmt-8 friday the 26th -igor
Re: disabled components/behaviors fixes of WICKET-3098
yes that i did see in 1.5
but in 1.4 i guess the only thing we can do is just introduce that
IIgnoreDisabledComponentBehavior interface (that doesnt have any
method)
(or something the same with a different name, any recomendations?)
johan
On Wed, Nov 24, 2010 at 16:57, Igor Vaynberg igor.vaynb...@gmail.com wrote:
i added boolean canCallListenerInterface(Component component) to ibehavior
-igor
On Wed, Nov 24, 2010 at 12:54 AM, Johan Compagner jcompag...@gmail.com
wrote:
which method name?
I currently only have a tagging interface that tags this behavior...
On Wed, Nov 24, 2010 at 03:00, Igor Vaynberg igor.vaynb...@gmail.com wrote:
i just fixed it in trunk. in 1.4 we dont really have a choice but to
add the mixin interface, but can you at least make the method name
match?
cheers,
-igor
On Tue, Nov 23, 2010 at 1:04 PM, Johan Compagner jcompag...@gmail.com
wrote:
that i find a big hack
then i need to have some none visible (in html not in java) label or
something.. thats horrible then i need to add all kinds of stuff.
I just want that behavior is executed. by a call. that call is not a
user event (at least not directly)
it is just (in this example) a resize event that is unrelated to the
component being disabled. Disabled is just the look in the ui it
doesnt mean that resizing shouldnt happen
I get that disabled behaviors shouldnt work, i also get that behaviors
shouldnt work on none visible components (there is no ui)
but disabled components is just a visual thing. that doesnt mean that
really all events are also disabled.
for example in Swing on a button yes the click event (ActionListenter)
is disabled but a ComponentListener (add/remove) still will work
fine..
johan
On Tue, Nov 23, 2010 at 21:52, Martin Grigorov mgrigo...@apache.org
wrote:
On Tue, Nov 23, 2010 at 11:02 AM, Johan Compagner
jcompag...@gmail.comwrote:
i am currently using this patch for our wicket code so that we can move
on..
First check is that if it is an ajax request for that behavior then
just throw an abort exception..
Dont just return null because the constantly a full page render is
done instead of the ajax behavior request.
Second is that i introduced an tagging interface so that behaviors can
make them self work for disabled components if they want to.
anybody a better idea?
What about adding a companion component for the resize logic ? I.e. the
ListView will be disabled, but the companion component will fire and
repaint
the ListView if necessary. This way you explicitly say that you want to
modify disabled component.
johan
### Eclipse Workspace Patch 1.0
#P wicket
Index:
src/main/java/org/apache/wicket/behavior/IIgnoreDisabledComponentBehavior.java
===
---
src/main/java/org/apache/wicket/behavior/IIgnoreDisabledComponentBehavior.java
(revision
0)
+++
src/main/java/org/apache/wicket/behavior/IIgnoreDisabledComponentBehavior.java
(revision
0)
@@ -0,0 +1,28 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version
2.0
+ * (the License); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an AS IS BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+package org.apache.wicket.behavior;
+
+/**
+ * Interface that can be used to tag behaviors where response should
be called on even if the
+ * component is disabled.
+ *
+ * @author jcompagner
+ */
+public interface IIgnoreDisabledComponentBehavior extends IBehavior
+{
+
+}
Index:
src/main/java/org/apache/wicket/request/target/component/listener/BehaviorRequestTarget.java
===
---
src/main/java/org/apache/wicket/request/target/component/listener/BehaviorRequestTarget.java
(revision
1033481)
+++
src/main/java/org/apache/wicket/request/target/component/listener/BehaviorRequestTarget.java
(working
copy)
@@ -18,13 +18,16 @@
import java.util.List;
+import org.apache.wicket.AbortException;
import org.apache.wicket.Component;
import org.apache.wicket.Page;
import org.apache.wicket.RequestCycle;
import org.apache.wicket.RequestListenerInterface;
import org.apache.wicket.behavior.IBehavior;
import org.apache.wicket.behavior.IBehaviorListener;
+import
Re: disabled components/behaviors fixes of WICKET-3098
that first one is a perfect name, except that the intent is that it
works just the opposite!
:)
On Wed, Nov 24, 2010 at 17:20, Martijn Dashorst
martijn.dasho...@gmail.com wrote:
IWontDoAnythingWhenTheComponentIsDisabledBehavior
IMASlackerBehavior
Martijn
On Wed, Nov 24, 2010 at 5:12 PM, Johan Compagner jcompag...@gmail.com wrote:
yes that i did see in 1.5
but in 1.4 i guess the only thing we can do is just introduce that
IIgnoreDisabledComponentBehavior interface (that doesnt have any
method)
(or something the same with a different name, any recomendations?)
johan
On Wed, Nov 24, 2010 at 16:57, Igor Vaynberg igor.vaynb...@gmail.com wrote:
i added boolean canCallListenerInterface(Component component) to ibehavior
-igor
On Wed, Nov 24, 2010 at 12:54 AM, Johan Compagner jcompag...@gmail.com
wrote:
which method name?
I currently only have a tagging interface that tags this behavior...
On Wed, Nov 24, 2010 at 03:00, Igor Vaynberg igor.vaynb...@gmail.com
wrote:
i just fixed it in trunk. in 1.4 we dont really have a choice but to
add the mixin interface, but can you at least make the method name
match?
cheers,
-igor
On Tue, Nov 23, 2010 at 1:04 PM, Johan Compagner jcompag...@gmail.com
wrote:
that i find a big hack
then i need to have some none visible (in html not in java) label or
something.. thats horrible then i need to add all kinds of stuff.
I just want that behavior is executed. by a call. that call is not a
user event (at least not directly)
it is just (in this example) a resize event that is unrelated to the
component being disabled. Disabled is just the look in the ui it
doesnt mean that resizing shouldnt happen
I get that disabled behaviors shouldnt work, i also get that behaviors
shouldnt work on none visible components (there is no ui)
but disabled components is just a visual thing. that doesnt mean that
really all events are also disabled.
for example in Swing on a button yes the click event (ActionListenter)
is disabled but a ComponentListener (add/remove) still will work
fine..
johan
On Tue, Nov 23, 2010 at 21:52, Martin Grigorov mgrigo...@apache.org
wrote:
On Tue, Nov 23, 2010 at 11:02 AM, Johan Compagner
jcompag...@gmail.comwrote:
i am currently using this patch for our wicket code so that we can move
on..
First check is that if it is an ajax request for that behavior then
just throw an abort exception..
Dont just return null because the constantly a full page render is
done instead of the ajax behavior request.
Second is that i introduced an tagging interface so that behaviors can
make them self work for disabled components if they want to.
anybody a better idea?
What about adding a companion component for the resize logic ? I.e. the
ListView will be disabled, but the companion component will fire and
repaint
the ListView if necessary. This way you explicitly say that you want to
modify disabled component.
johan
### Eclipse Workspace Patch 1.0
#P wicket
Index:
src/main/java/org/apache/wicket/behavior/IIgnoreDisabledComponentBehavior.java
===
---
src/main/java/org/apache/wicket/behavior/IIgnoreDisabledComponentBehavior.java
(revision
0)
+++
src/main/java/org/apache/wicket/behavior/IIgnoreDisabledComponentBehavior.java
(revision
0)
@@ -0,0 +1,28 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed
with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License,
Version 2.0
+ * (the License); you may not use this file except in compliance
with
+ * the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an AS IS BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+package org.apache.wicket.behavior;
+
+/**
+ * Interface that can be used to tag behaviors where response should
be called on even if the
+ * component is disabled.
+ *
+ * @author jcompagner
+ */
+public interface IIgnoreDisabledComponentBehavior extends IBehavior
+{
+
+}
Index:
src/main/java/org/apache/wicket/request/target/component/listener/BehaviorRequestTarget.java
===
---
src/main/java/org/apache/wicket/request/target/component/listener/BehaviorRequestTarget.java
(revision
1033481)
+++
src/main/java/org/apache/wicket/request/target/component/listener/BehaviorRequestTarget.java
(working
copy)
@@ -18,13 +18,16 @@
import java.util.List
Re: disabled components/behaviors fixes of WICKET-3098
And then completely remove the check if the component is disabled i guess?
That would work for me but then if users dont really call super() when
they have there own enable logic that would mean it would always be
called..
(because now it just returns true so people could think i dont need to
call super)
On Wed, Nov 24, 2010 at 17:21, Pedro Santos pedros...@gmail.com wrote:
Why don't simple change the AbstractBehavior default isEnabled
implementation to respect the component state, like:
public boolean isEnabled(Component component)
{
return component.isEnabled();
}
It would solve the problem at the ticket. IMO the proposed interface is
prolix because the behavior enabled/disabled state is enough information to
decide to silent return or not an ajax call to it.
On Wed, Nov 24, 2010 at 2:12 PM, Johan Compagner jcompag...@gmail.comwrote:
yes that i did see in 1.5
but in 1.4 i guess the only thing we can do is just introduce that
IIgnoreDisabledComponentBehavior interface (that doesnt have any
method)
(or something the same with a different name, any recomendations?)
johan
On Wed, Nov 24, 2010 at 16:57, Igor Vaynberg igor.vaynb...@gmail.com
wrote:
i added boolean canCallListenerInterface(Component component) to
ibehavior
-igor
On Wed, Nov 24, 2010 at 12:54 AM, Johan Compagner jcompag...@gmail.com
wrote:
which method name?
I currently only have a tagging interface that tags this behavior...
On Wed, Nov 24, 2010 at 03:00, Igor Vaynberg igor.vaynb...@gmail.com
wrote:
i just fixed it in trunk. in 1.4 we dont really have a choice but to
add the mixin interface, but can you at least make the method name
match?
cheers,
-igor
On Tue, Nov 23, 2010 at 1:04 PM, Johan Compagner jcompag...@gmail.com
wrote:
that i find a big hack
then i need to have some none visible (in html not in java) label or
something.. thats horrible then i need to add all kinds of stuff.
I just want that behavior is executed. by a call. that call is not a
user event (at least not directly)
it is just (in this example) a resize event that is unrelated to the
component being disabled. Disabled is just the look in the ui it
doesnt mean that resizing shouldnt happen
I get that disabled behaviors shouldnt work, i also get that behaviors
shouldnt work on none visible components (there is no ui)
but disabled components is just a visual thing. that doesnt mean that
really all events are also disabled.
for example in Swing on a button yes the click event (ActionListenter)
is disabled but a ComponentListener (add/remove) still will work
fine..
johan
On Tue, Nov 23, 2010 at 21:52, Martin Grigorov mgrigo...@apache.org
wrote:
On Tue, Nov 23, 2010 at 11:02 AM, Johan Compagner
jcompag...@gmail.comwrote:
i am currently using this patch for our wicket code so that we can
move
on..
First check is that if it is an ajax request for that behavior then
just throw an abort exception..
Dont just return null because the constantly a full page render is
done instead of the ajax behavior request.
Second is that i introduced an tagging interface so that behaviors
can
make them self work for disabled components if they want to.
anybody a better idea?
What about adding a companion component for the resize logic ? I.e.
the
ListView will be disabled, but the companion component will fire and
repaint
the ListView if necessary. This way you explicitly say that you want
to
modify disabled component.
johan
### Eclipse Workspace Patch 1.0
#P wicket
Index:
src/main/java/org/apache/wicket/behavior/IIgnoreDisabledComponentBehavior.java
===
---
src/main/java/org/apache/wicket/behavior/IIgnoreDisabledComponentBehavior.java
(revision
0)
+++
src/main/java/org/apache/wicket/behavior/IIgnoreDisabledComponentBehavior.java
(revision
0)
@@ -0,0 +1,28 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or
more
+ * contributor license agreements. See the NOTICE file distributed
with
+ * this work for additional information regarding copyright
ownership.
+ * The ASF licenses this file to You under the Apache License,
Version 2.0
+ * (the License); you may not use this file except in compliance
with
+ * the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
software
+ * distributed under the License is distributed on an AS IS
BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
implied.
+ * See the License for the specific language governing permissions
and
+ * limitations under the License.
+ */
+package org.apache.wicket.behavior;
+
+/**
+ * Interface that can be used to tag behaviors where response
Re: disabled components/behaviors fixes of WICKET-3098
ok then i check my changes in for 1.4
So that at least people that use 1.4 (like us) can use that one for now.
I can add a note in the doc that this will be replaced by 1.5 completely..
On Wed, Nov 24, 2010 at 17:15, Igor Vaynberg igor.vaynb...@gmail.com wrote:
i dont think the name of the mixin matters much because 1.5 is out
soonish. IListenerInterfaceTarget { canCallListenerInterface()} is not
so bad.
-igor
On Wed, Nov 24, 2010 at 8:12 AM, Johan Compagner jcompag...@gmail.com wrote:
yes that i did see in 1.5
but in 1.4 i guess the only thing we can do is just introduce that
IIgnoreDisabledComponentBehavior interface (that doesnt have any
method)
(or something the same with a different name, any recomendations?)
johan
On Wed, Nov 24, 2010 at 16:57, Igor Vaynberg igor.vaynb...@gmail.com wrote:
i added boolean canCallListenerInterface(Component component) to ibehavior
-igor
On Wed, Nov 24, 2010 at 12:54 AM, Johan Compagner jcompag...@gmail.com
wrote:
which method name?
I currently only have a tagging interface that tags this behavior...
On Wed, Nov 24, 2010 at 03:00, Igor Vaynberg igor.vaynb...@gmail.com
wrote:
i just fixed it in trunk. in 1.4 we dont really have a choice but to
add the mixin interface, but can you at least make the method name
match?
cheers,
-igor
On Tue, Nov 23, 2010 at 1:04 PM, Johan Compagner jcompag...@gmail.com
wrote:
that i find a big hack
then i need to have some none visible (in html not in java) label or
something.. thats horrible then i need to add all kinds of stuff.
I just want that behavior is executed. by a call. that call is not a
user event (at least not directly)
it is just (in this example) a resize event that is unrelated to the
component being disabled. Disabled is just the look in the ui it
doesnt mean that resizing shouldnt happen
I get that disabled behaviors shouldnt work, i also get that behaviors
shouldnt work on none visible components (there is no ui)
but disabled components is just a visual thing. that doesnt mean that
really all events are also disabled.
for example in Swing on a button yes the click event (ActionListenter)
is disabled but a ComponentListener (add/remove) still will work
fine..
johan
On Tue, Nov 23, 2010 at 21:52, Martin Grigorov mgrigo...@apache.org
wrote:
On Tue, Nov 23, 2010 at 11:02 AM, Johan Compagner
jcompag...@gmail.comwrote:
i am currently using this patch for our wicket code so that we can move
on..
First check is that if it is an ajax request for that behavior then
just throw an abort exception..
Dont just return null because the constantly a full page render is
done instead of the ajax behavior request.
Second is that i introduced an tagging interface so that behaviors can
make them self work for disabled components if they want to.
anybody a better idea?
What about adding a companion component for the resize logic ? I.e. the
ListView will be disabled, but the companion component will fire and
repaint
the ListView if necessary. This way you explicitly say that you want to
modify disabled component.
johan
### Eclipse Workspace Patch 1.0
#P wicket
Index:
src/main/java/org/apache/wicket/behavior/IIgnoreDisabledComponentBehavior.java
===
---
src/main/java/org/apache/wicket/behavior/IIgnoreDisabledComponentBehavior.java
(revision
0)
+++
src/main/java/org/apache/wicket/behavior/IIgnoreDisabledComponentBehavior.java
(revision
0)
@@ -0,0 +1,28 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed
with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License,
Version 2.0
+ * (the License); you may not use this file except in compliance
with
+ * the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an AS IS BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+package org.apache.wicket.behavior;
+
+/**
+ * Interface that can be used to tag behaviors where response should
be called on even if the
+ * component is disabled.
+ *
+ * @author jcompagner
+ */
+public interface IIgnoreDisabledComponentBehavior extends IBehavior
+{
+
+}
Index:
src/main/java/org/apache/wicket/request/target/component/listener/BehaviorRequestTarget.java
===
---
src/main/java/org/apache/wicket/request/target/component/listener/BehaviorRequestTarget.java
(revision
1033481)
+++
src
disabled components/behaviors fixes of WICKET-3098
hi, i suddenly bump big time into this issue that is fixed. ( https://issues.apache.org/jira/browse/WICKET-3098 ) I get that disabled behaviors can't be used to do respond, because that behavior shouldnt be rendered in the first place. But the fix also goes one step deeper... It also blocks if the component is disabled.. That is a big problem Because a disabled component is rendered, and all the behaviors are accepted and rendered also so now suddenly a behavior is rendered (because the behavior is not disabled) but a callback will fail... thats something i dont like...because now i get loads of these in the log: 2010-11-23 09:10:57,934 WARN [http-8080-1] org.apache.wicket.request.target.component.listener.BehaviorRequestTarget - component not enabled or visible; ignoring call. Component: [MarkupContainer [Component id = View]] and the worse thing is if the behavior blocks like that it fall backs to a IRedirectListener so it rerenders the whole page and that again renders the disabled component with its behavior and it starts all over again and again and again. the example i have here is that we have a ListView/Repeater with some paging component and that listview has a behavior attached that does a call back when it got first rendered to give us back the sizes it has in the browser and if we see that it has way more space then it currently shows (if it now shows 10 rows and it has space for 20) we rerender the ListView again but then with a bigger visible row count. that is a behavior of the ListView, but the listview can be in a disabled state (because a user first have to press a button of edit or something like that) but that resizing i still want to happen if if the ListView is disabled... So i like to some how tell that that this behavior should be called. Now we do this: test component enablement test behavior id test behaviors test behaviors enabledment. call behavior i like to turn that around test behavior id test behaviors test behaviors enabledment. test component enablement IF behavior doesnt implement IWorkForDisabledComponent call behavior So that a developer can be explicit in that check.. We could also introduce a public method on Component: isEnabledFor(IBehavior) which returns defaults its own enable state. johan
Re: disabled components/behaviors fixes of WICKET-3098
()).isAjax())
+ {
+ throw new AbortException();
+ }
+ return;
+ }
+
+
// Invoke the interface method
behaviorListener.onRequest();
}
On Tue, Nov 23, 2010 at 09:42, Johan Compagner jcompag...@gmail.com wrote:
hi,
i suddenly bump big time into this issue that is fixed.
( https://issues.apache.org/jira/browse/WICKET-3098 )
I get that disabled behaviors can't be used to do respond, because
that behavior shouldnt be rendered in the first place.
But the fix also goes one step deeper... It also blocks if the
component is disabled.. That is a big problem
Because a disabled component is rendered, and all the behaviors are
accepted and rendered also so now suddenly a behavior is rendered
(because the behavior is not disabled)
but a callback will fail...
thats something i dont like...because now i get loads of these in the log:
2010-11-23 09:10:57,934 WARN [http-8080-1]
org.apache.wicket.request.target.component.listener.BehaviorRequestTarget
- component not enabled or visible; ignoring call. Component:
[MarkupContainer [Component id = View]]
and the worse thing is if the behavior blocks like that it fall backs
to a IRedirectListener so it rerenders the whole page and that again
renders the disabled component with its behavior and it starts all
over again and again and again.
the example i have here is that we have a ListView/Repeater with some
paging component and that listview has a behavior attached that does a
call back when it got first rendered to give us back the sizes it has
in the browser
and if we see that it has way more space then it currently shows (if
it now shows 10 rows and it has space for 20) we rerender the ListView
again but then with a bigger visible row count.
that is a behavior of the ListView, but the listview can be in a
disabled state (because a user first have to press a button of edit
or something like that) but that resizing i still want to happen if if
the ListView is disabled...
So i like to some how tell that that this behavior should be called.
Now we do this:
test component enablement
test behavior id
test behaviors
test behaviors enabledment.
call behavior
i like to turn that around
test behavior id
test behaviors
test behaviors enabledment.
test component enablement IF behavior doesnt implement
IWorkForDisabledComponent
call behavior
So that a developer can be explicit in that check..
We could also introduce a public method on Component:
isEnabledFor(IBehavior) which returns defaults its own enable state.
johan
Re: disabled components/behaviors fixes of WICKET-3098
that i find a big hack
then i need to have some none visible (in html not in java) label or
something.. thats horrible then i need to add all kinds of stuff.
I just want that behavior is executed. by a call. that call is not a
user event (at least not directly)
it is just (in this example) a resize event that is unrelated to the
component being disabled. Disabled is just the look in the ui it
doesnt mean that resizing shouldnt happen
I get that disabled behaviors shouldnt work, i also get that behaviors
shouldnt work on none visible components (there is no ui)
but disabled components is just a visual thing. that doesnt mean that
really all events are also disabled.
for example in Swing on a button yes the click event (ActionListenter)
is disabled but a ComponentListener (add/remove) still will work
fine..
johan
On Tue, Nov 23, 2010 at 21:52, Martin Grigorov mgrigo...@apache.org wrote:
On Tue, Nov 23, 2010 at 11:02 AM, Johan Compagner jcompag...@gmail.comwrote:
i am currently using this patch for our wicket code so that we can move
on..
First check is that if it is an ajax request for that behavior then
just throw an abort exception..
Dont just return null because the constantly a full page render is
done instead of the ajax behavior request.
Second is that i introduced an tagging interface so that behaviors can
make them self work for disabled components if they want to.
anybody a better idea?
What about adding a companion component for the resize logic ? I.e. the
ListView will be disabled, but the companion component will fire and repaint
the ListView if necessary. This way you explicitly say that you want to
modify disabled component.
johan
### Eclipse Workspace Patch 1.0
#P wicket
Index:
src/main/java/org/apache/wicket/behavior/IIgnoreDisabledComponentBehavior.java
===
---
src/main/java/org/apache/wicket/behavior/IIgnoreDisabledComponentBehavior.java
(revision
0)
+++
src/main/java/org/apache/wicket/behavior/IIgnoreDisabledComponentBehavior.java
(revision
0)
@@ -0,0 +1,28 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the License); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an AS IS BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+package org.apache.wicket.behavior;
+
+/**
+ * Interface that can be used to tag behaviors where response should
be called on even if the
+ * component is disabled.
+ *
+ * @author jcompagner
+ */
+public interface IIgnoreDisabledComponentBehavior extends IBehavior
+{
+
+}
Index:
src/main/java/org/apache/wicket/request/target/component/listener/BehaviorRequestTarget.java
===
---
src/main/java/org/apache/wicket/request/target/component/listener/BehaviorRequestTarget.java
(revision
1033481)
+++
src/main/java/org/apache/wicket/request/target/component/listener/BehaviorRequestTarget.java
(working
copy)
@@ -18,13 +18,16 @@
import java.util.List;
+import org.apache.wicket.AbortException;
import org.apache.wicket.Component;
import org.apache.wicket.Page;
import org.apache.wicket.RequestCycle;
import org.apache.wicket.RequestListenerInterface;
import org.apache.wicket.behavior.IBehavior;
import org.apache.wicket.behavior.IBehaviorListener;
+import org.apache.wicket.behavior.IIgnoreDisabledComponentBehavior;
import org.apache.wicket.protocol.http.PageExpiredException;
+import org.apache.wicket.protocol.http.WebRequest;
import org.apache.wicket.request.RequestParameters;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
@@ -85,13 +88,6 @@
// Get the IBehavior for the component based on the request
parameters
final Component component = getTarget();
- if (!component.isVisibleInHierarchy() ||
!component.isEnabledInHierarchy())
- {
- // ignore this request
- logger.warn(component not enabled or visible;
ignoring call.
Component: {}, component);
- return;
- }
-
final String id = getRequestParameters().getBehaviorId();
if (id == null)
{
@@ -124,6 +120,11
Re: wicketstuff.org/hudson - No space left on device
should be ok now. On Sun, Oct 31, 2010 at 12:30, Sebastian nospam...@gmx.net wrote: hi, can someone please free some diskspace on the wicketstuff hudson server please. I receive Error deploying artifact: Error creating temporary file for deployment: No space left on device when trying to trigger a build. thanks! Seb
Re: TimeOfDay problem with DTS
this is known issue from day 1 :) it is a test that fails 2 times a year.. dont think anybody bothers about it :) On Sun, Oct 31, 2010 at 14:02, Martin Grigorov mgrigo...@apache.org wrote: Hi, Locally org.apache.wicket.util.time.TimeOfDayTest.test() fails today due to Daylight Time Savings change last night. Is this a bug in TimeOfDay that we care about ? Setting the default time zone to one without DTS (e.g. 'GMT') makes the test pass. martin-g
Re: [vote] release wicket 1.4.12
+1 On Mon, Sep 13, 2010 at 05:45, Igor Vaynberg igor.vaynb...@gmail.com wrote: This vote is to release wicket 1.4.12. This release fixes a critical problem with 1.4.11 namely WICKET-3040. Branch: http://svn.apache.org/repos/asf/wicket/branches/wicket-1.4.12/ Artifacts: http://people.apache.org/~ivaynberg/wicket-1.4.12/dist Maven repo: http://people.apache.org/~ivaynberg/wicket-1.4.12/m2-repo Changelog: https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=truepid=12310561fixfor=12315312sorter/field=prioritysorter/order=DESC This vote ends Thursday 9:00am GMT-8 Please test the release and offer your vote: [ ] Yes, release [ ] No, don't release it (and please tell us why) ChangeLog Release Notes - Wicket - Version 1.4.12 ** Sub-task * [WICKET-3037] - InnerFeedbackTest test fails due locale issue ** Bug * [WICKET-1743] - WicketTester fires onSubmit for first form button prior to firing requested ajax event * [WICKET-3032] - WebApplication#mountBookmarkablePage with unicode path not works. * [WICKET-3033] - Stack Overflow in getBeanDefinition()'s of SpringBeanLocator and AnnotProxyFieldValueFactory * [WICKET-3040] - Ajax form submit fails in Wicket 1.4.11/Firefox3.6 * [WICKET-3043] - Ajax support broken under Firefox 3.6.x and Wicket 1.4.11 ** Improvement * [WICKET-2922] - AutoCompleteTextField should allow the generics specification for the getChoices iterator and the type of the model ** Task * [WICKET-3041] - Relative link in JavaScript
Re: [vote] release wicket 1.4.11
+1 release On Sun, Sep 5, 2010 at 05:12, Igor Vaynberg igor.vaynb...@gmail.com wrote: This vote is to release wicket 1.4.11 Branch: http://svn.apache.org/repos/asf/wicket/branches/wicket-1.4.11/ Artifacts: http://people.apache.org/~ivaynberg/wicket-1.4.11/dist Maven repo: http://people.apache.org/~ivaynberg/wicket-1.4.11/m2-repo Changelog: https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=truepid=12310561fixfor=12315236sorter/field=issuekeysorter/order=DESC This vote ends Tuesday 21:00 GMT-8 Please test the release and offer your vote: [ ] Yes, release [ ] No, don't release it (and please tell us why) ChangeLog Sub-task [WICKET-2625] - WICKET-2478 correction are break Bug [WICKET-1094] - Values over-escaped by FormTester [WICKET-1448] - SubmitLink bypass jquery submit eventhandler [WICKET-1733] - WicketTester doesn't include form submitting component id in form submissions [WICKET-1887] - 404 error page customize - with specified url-pattern (not /*) [WICKET-1928] - Enter key submits form in AjaxEditableMultiLineLabel on Safari [WICKET-1985] - AbstractTree breaks on multiple tree model events in the same request [WICKET-2010] - InspectorPage doesn't show component tree [WICKET-2254] - ModalWindow size may exceed browser viewport making it impossible to close [WICKET-2262] - The starting of the ajax indicator don't respect AbstractDefaultAjaxBehavior preconditionScript [WICKET-2275] - HybridUrlCodingStrategy does not support parameters with a . [WICKET-2279] - Losing focus on Autocomplete field if DropDownChoice is updated using Ajax. [WICKET-2353] - CLONE -wicket:enclosure bug: setObject(null) called for excplicitly invisible fields in a non-visible enclosure [WICKET-2401] - AJAX indicator turns off when calls overlap [WICKET-2712] - Wrong relative URL's when using Java EE 6 container with ERROR dispatching [WICKET-2739] - Throttling breaks AjaxFormSubmitBehavior's precondition check [WICKET-2765] - MarkupException on unclosed col tag [WICKET-2783] - FormTester.submit does not work with AjaxButtons [WICKET-2793] - Incorrect decode parameters in AbstractRequestTargetUrlCodingStrategy#decodeParameters [WICKET-2794] - Not all exceptions are properly handled by the WicketFilter - results in empty response document with unset status code - seen as HTTP_OK by client [WICKET-2807] - AjaxSubmitLink not calling the onsubmit event handler [WICKET-2826] - Wicket fails to read html markup from jar after updating and redeploying in jetty [WICKET-2827] - Removed page might revive when push back-button [WICKET-2828] - IndexOutOfBoundsException is thrown in onBeforeRender when tabs is empty. [WICKET-2848] - Rename yahoo-dom-event folder to something else [WICKET-2850] - Wicket DateTimeField / DatePicker creates a memory leak on the browser when rerenderd using ajax requests [WICKET-2851] - Ajax responses do not update DOM correctly on Opera [WICKET-2852] - Palette nested in a ListView results in a NPE when an error feedback is logged when submitting form [WICKET-2854] - 'this.document' is null or not an object after quickly opening and closing a modal window (modal.js) [WICKET-2863] - MockHttpServletResponse does not save Session cookies (maxAge = -1) [WICKET-2877] - PreCallHandler and PostCallHandler registrations are lost when ;jsessionid is removed in javascript files URL [WICKET-2886] - Tree doesn't update correctly [WICKET-2903] - CLONE -HttpsRequestCycleProcessor causes HttpSession to be created [WICKET-2905] - Select.isSelected fails when Wicket application is using REDIRECT_TO_RENDER render strategy. [WICKET-2931] - Form#getMaxSize - unsupported in the inner forms [WICKET-2933] - Form.MULTIPART_HINT is not cleared correctly with nested forms [WICKET-2941] - DatePicker fail with firstDate is undefined when an out of range date is written in the textfield [WICKET-2944] - Application addRenderHeadListener causing error [WICKET-2957] - Closing ModalWindow makes some form fields unclickable [WICKET-2958] - Success handler not called when redirecting with Ajax [WICKET-2972] - Some RepeaterView examples are not working [WICKET-2974] - IFeedback that is child of IFeedback gets added to the FEEDBACK_LIST too late [WICKET-2977] - AutoComplete onfocus behavior only working on last autocomplete field [WICKET-2999] - Packaged Resource URLs encoded with jsessionid [WICKET-3014] - unable to launch StartExamples from IDEA (eventually other IDE's as well) [WICKET-3018] - CheckGroupSelector ignores disabled-state in Check [WICKET-3025] - DateTextField converter does not honor current locale Improvement [WICKET-2964] - Improve the code that uses copy-list-on-iterate pattern [WICKET-2978] - Usage of SimpleFormComponentLabel in FormInput example [WICKET-3002] - Resource.getResourceStream() javadoc improvements (patch) [WICKET-3019] - Add getPath to MarkupExceptions to aid in locatin affected components New Feature
Re: POST request comes as GET in wicket
when do you test this? ((WebRequestCycle)RequestCycle.get()).getWebRequest().getHttpServletRequest().getMethod(), and why do you care if it is a get or post? On Thu, Aug 19, 2010 at 22:15, ganesh.k...@gmail.com ganesh.k...@gmail.com wrote: TITLE New Document /TITLE META NAME=Generator CONTENT=EditPlus META NAME=Author CONTENT= META NAME=Keywords CONTENT= META NAME=Description CONTENT= /HEAD BODY form method=POST action=http://x.x.x.x/rootContext/subcontext; INPUT TYPE=text NAME=your_name VALUE=First Last INPUT TYPE=submit VALUE=Test this form /form /BODY /HTML But when I look up ((WebRequestCycle)RequestCycle.get()).getWebRequest().getHttpServletRequest().getMethod(). it comes as GET and the parameter list is also zero. I am new to Wicket, so obviously missing something very simple and basic. Can someone provide some pointers? -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/POST-request-comes-as-GET-in-wicket-tp2331816p2331816.html Sent from the Wicket - Dev mailing list archive at Nabble.com.
Re: /var is full on wicketsuff.org
cleaned it On Tue, Aug 17, 2010 at 03:04, Michael O'Cleirigh michael.ocleir...@rivulet.ca wrote: Hello, Hudson on wicketstuff.org is failing to build anything because of a lack of temporary space. I created a job to run nightly and attempt to clean up some space. Normally I have seen the local repository grow very large but in this case cleaning it doesn't work. I did a df -kh and was able to see that the /var partition is the one with issues and is full at 104% (with -135M free). Could I get a hint on the location that needs to be cleaned up and how it is related to hudson? The build works to download the source, build and install the artifacts but during deploy it hits /var in a way I can't figure out. For example: http://wicketstuff.org/hudson/job/Wicket%20Stuff%20Core%20Parent%20%28wicket%201.4-SNAPSHOT%29/lastFailedBuild/console I read about a log rolling issue that existed in the past. If this is still present perhaps a script can be created and called from the hudson job to periodically reclaim space from /var. Thanks for your help and let me know if there is anything I can do to resolve this issue, Mike
Re: Update examples at wicketstuff.org
i see that teamcity is gone now, and we use hudson, but that doesnt build wicket-examples So the easy copy file that i have doesnt work anymore.. On Thu, Aug 12, 2010 at 15:09, Martin Grigorov mgrigo...@apache.org wrote: Hi, I would like to ask wicketstuff.org maintainers to update the examples deployed at this machine to latest 1.4.10 and 1.5-M1 versions. Recently we had a ticket about broken 1.4 examples but everything was fine in the latest snapshot (running the examples locally). Do you think it is a good idea to run the examples in DEVELOPMENT mode so we and the users can see the problem in the browser instead of asking for logs ? martin-g
Re: Can jjava 5 update 22 be installed on the wicketstuff.org server?
at the moment 1.5.0_13-p7 does run there. And i dont know how to update that under freebsd. On Thu, Aug 12, 2010 at 14:53, Michael O'Cleirigh michael.ocleir...@rivulet.ca wrote: Hello, With the version of java 5 currently installed on wicketstuff.org hudson gives build errors with one of the jwicket projects (related to instanceof outerclass?.innerClass, a generics issue). But compiling in Linux and Windows using the latest jdk5 update 22 results in no compile error. I tried to use the hudson auto jdk installer but it doesn't seem to work for FreeBSD: JDK installation skipped: Unknown CPU name: freebsd JDK installation skipped: Unknown CPU name: freebsd Would someone with the correct access be able to install the jdk update 22 onto the wicketstuff.org server? This won't effect my ability to cut a wicketstuff-core 1.4.10 release but it would be nice if all the jwicket artifacts can have a latest snapshot version. Thanks, Mike
Re: Can jjava 5 update 22 be installed on the wicketstuff.org server?
i think i can get _16 on it if i get it right.. But not sure if that would fix your compile problem On Thu, Aug 12, 2010 at 15:55, Johan Compagner jcompag...@gmail.com wrote: at the moment 1.5.0_13-p7 does run there. And i dont know how to update that under freebsd. On Thu, Aug 12, 2010 at 14:53, Michael O'Cleirigh michael.ocleir...@rivulet.ca wrote: Hello, With the version of java 5 currently installed on wicketstuff.org hudson gives build errors with one of the jwicket projects (related to instanceof outerclass?.innerClass, a generics issue). But compiling in Linux and Windows using the latest jdk5 update 22 results in no compile error. I tried to use the hudson auto jdk installer but it doesn't seem to work for FreeBSD: JDK installation skipped: Unknown CPU name: freebsd JDK installation skipped: Unknown CPU name: freebsd Would someone with the correct access be able to install the jdk update 22 onto the wicketstuff.org server? This won't effect my ability to cut a wicketstuff-core 1.4.10 release but it would be nice if all the jwicket artifacts can have a latest snapshot version. Thanks, Mike
Re: Update examples at wicketstuff.org
ok if that is stable then thats fine i updated the copywicket14.sh file: wget -Owicket14.war 'http://hudson.zones.apache.org/hudson/job/Apache%20Wicket%201.4.x/ws/wicket-1.4.x/wicket-examples/target/wicket-examples.war' and did run it so you should have the latest now. On Thu, Aug 12, 2010 at 16:55, Martin Grigorov mgrigo...@apache.org wrote: Here is a URL to latest build at Hudson: http://hudson.zones.apache.org/hudson/job/Apache%20Wicket%201.4.x/ws/wicket-1.4.x/wicket-examples/target/wicket-examples.war I think this is a stable URL so we can use it. On Thu, Aug 12, 2010 at 3:50 PM, Johan Compagner jcompag...@gmail.comwrote: i see that teamcity is gone now, and we use hudson, but that doesnt build wicket-examples So the easy copy file that i have doesnt work anymore.. On Thu, Aug 12, 2010 at 15:09, Martin Grigorov mgrigo...@apache.org wrote: Hi, I would like to ask wicketstuff.org maintainers to update the examples deployed at this machine to latest 1.4.10 and 1.5-M1 versions. Recently we had a ticket about broken 1.4 examples but everything was fine in the latest snapshot (running the examples locally). Do you think it is a good idea to run the examples in DEVELOPMENT mode so we and the users can see the problem in the browser instead of asking for logs ? martin-g
Re: svn commit: r984800 - /wicket/branches/wicket-1.4.x/wicket-extensions/src/main/java/org/apache/wicket/extensions/ajax/markup/html/autocomplete/wicket-autocomplete.js
thats something else but i also fixed that one quickly
On Thu, Aug 12, 2010 at 16:57, Martin Grigorov mgrigo...@apache.org wrote:
Is this related to https://issues.apache.org/jira/browse/WICKET-2977 or this
is something different ?
On Thu, Aug 12, 2010 at 4:23 PM, jcompag...@apache.org wrote:
Author: jcompagner
Date: Thu Aug 12 14:23:34 2010
New Revision: 984800
URL: http://svn.apache.org/viewvc?rev=984800view=rev
Log:
fix for double characters autocomplete and Upper Case
Modified:
wicket/branches/wicket-1.4.x/wicket-extensions/src/main/java/org/apache/wicket/extensions/ajax/markup/html/autocomplete/wicket-autocomplete.js
Modified:
wicket/branches/wicket-1.4.x/wicket-extensions/src/main/java/org/apache/wicket/extensions/ajax/markup/html/autocomplete/wicket-autocomplete.js
URL:
http://svn.apache.org/viewvc/wicket/branches/wicket-1.4.x/wicket-extensions/src/main/java/org/apache/wicket/extensions/ajax/markup/html/autocomplete/wicket-autocomplete.js?rev=984800r1=984799r2=984800view=diff
==
---
wicket/branches/wicket-1.4.x/wicket-extensions/src/main/java/org/apache/wicket/extensions/ajax/markup/html/autocomplete/wicket-autocomplete.js
(original)
+++
wicket/branches/wicket-1.4.x/wicket-extensions/src/main/java/org/apache/wicket/extensions/ajax/markup/html/autocomplete/wicket-autocomplete.js
Thu Aug 12 14:23:34 2010
@@ -97,7 +97,7 @@ Wicket.AutoComplete=function(elementId,
objonchangeoriginal=obj.onchange;
obj.onchange=function(event){
if(mouseactive==1)return false;
- if(typeof
objonchangeoriginal==function)objonchangeoriginal.apply(this,[event]);
+ if(typeof objonchangeoriginal==function) return
objonchangeoriginal.apply(this,[event]);
}
objonchange=obj.onchange;
@@ -108,7 +108,7 @@ Wicket.AutoComplete=function(elementId,
return killEvent(event);
}
hideAutoComplete();
- if(typeof
objonblur==function)objonblur.apply(this,[event]);
+ if(typeof objonblur==function) return
objonblur.apply(this,[event]);
}
obj.onfocus=function(event){
@@ -124,7 +124,7 @@ Wicket.AutoComplete=function(elementId,
}
}
ignoreOneFocusGain = false;
- if(typeof
objonfocus==function)objonfocus.apply(this,[event]);
+ if(typeof objonfocus==function) return
objonfocus.apply(this,[event]);
}
obj.onkeydown=function(event){
@@ -170,7 +170,7 @@ Wicket.AutoComplete=function(elementId,
hidingAutocomplete = 1;
}
mouseactive = 0;
- if (typeof objonkeydown==function)
objonkeydown.apply(this,[event]);
+ if (typeof objonkeydown==function) return
objonkeydown.apply(this,[event]);
return true;
break;
default:
@@ -194,7 +194,7 @@ Wicket.AutoComplete=function(elementId,
default:
updateChoices();
}
- if(typeof
objonkeyup==function)objonkeyup.apply(this,[event]);
+ if(typeof objonkeyup==function) return
objonkeyup.apply(this,[event]);
}
obj.onkeypress=function(event){
@@ -204,7 +204,7 @@ Wicket.AutoComplete=function(elementId,
return killEvent(event);
}
}
- if(typeof
objonkeypress==function)objonkeypress.apply(this,[event]);
+ if(typeof objonkeypress==function) return
objonkeypress.apply(this,[event]);
}
}
Re: Update examples at wicketstuff.org
there is no such file with the extention .warplease ;) On Thu, Aug 12, 2010 at 17:12, Martin Grigorov mgrigo...@apache.org wrote: And the same for http://hudson.zones.apache.org/hudson/job/Apache%20Wicket%201.5.x/ws/trunk/wicket-examples/target/wicket-examples.warplease :-) Maybe we can rename http://wicketstuff.org/wicket/ to http://wicketstuff.org/wicket15/ http://wicketstuff.org/wicket/ ? On Thu, Aug 12, 2010 at 5:05 PM, Johan Compagner jcompag...@gmail.comwrote: ok if that is stable then thats fine i updated the copywicket14.sh file: wget -Owicket14.war ' http://hudson.zones.apache.org/hudson/job/Apache%20Wicket%201.4.x/ws/wicket-1.4.x/wicket-examples/target/wicket-examples.war ' and did run it so you should have the latest now. On Thu, Aug 12, 2010 at 16:55, Martin Grigorov mgrigo...@apache.org wrote: Here is a URL to latest build at Hudson: http://hudson.zones.apache.org/hudson/job/Apache%20Wicket%201.4.x/ws/wicket-1.4.x/wicket-examples/target/wicket-examples.war I think this is a stable URL so we can use it. On Thu, Aug 12, 2010 at 3:50 PM, Johan Compagner jcompag...@gmail.com wrote: i see that teamcity is gone now, and we use hudson, but that doesnt build wicket-examples So the easy copy file that i have doesnt work anymore.. On Thu, Aug 12, 2010 at 15:09, Martin Grigorov mgrigo...@apache.org wrote: Hi, I would like to ask wicketstuff.org maintainers to update the examples deployed at this machine to latest 1.4.10 and 1.5-M1 versions. Recently we had a ticket about broken 1.4 examples but everything was fine in the latest snapshot (running the examples locally). Do you think it is a good idea to run the examples in DEVELOPMENT mode so we and the users can see the problem in the browser instead of asking for logs ? martin-g
Re: Update examples at wicketstuff.org
done, trunk - wicket On Thu, Aug 12, 2010 at 17:14, Johan Compagner jcompag...@gmail.com wrote: there is no such file with the extention .warplease ;) On Thu, Aug 12, 2010 at 17:12, Martin Grigorov mgrigo...@apache.org wrote: And the same for http://hudson.zones.apache.org/hudson/job/Apache%20Wicket%201.5.x/ws/trunk/wicket-examples/target/wicket-examples.warplease :-) Maybe we can rename http://wicketstuff.org/wicket/ to http://wicketstuff.org/wicket15/ http://wicketstuff.org/wicket/ ? On Thu, Aug 12, 2010 at 5:05 PM, Johan Compagner jcompag...@gmail.comwrote: ok if that is stable then thats fine i updated the copywicket14.sh file: wget -Owicket14.war ' http://hudson.zones.apache.org/hudson/job/Apache%20Wicket%201.4.x/ws/wicket-1.4.x/wicket-examples/target/wicket-examples.war ' and did run it so you should have the latest now. On Thu, Aug 12, 2010 at 16:55, Martin Grigorov mgrigo...@apache.org wrote: Here is a URL to latest build at Hudson: http://hudson.zones.apache.org/hudson/job/Apache%20Wicket%201.4.x/ws/wicket-1.4.x/wicket-examples/target/wicket-examples.war I think this is a stable URL so we can use it. On Thu, Aug 12, 2010 at 3:50 PM, Johan Compagner jcompag...@gmail.com wrote: i see that teamcity is gone now, and we use hudson, but that doesnt build wicket-examples So the easy copy file that i have doesnt work anymore.. On Thu, Aug 12, 2010 at 15:09, Martin Grigorov mgrigo...@apache.org wrote: Hi, I would like to ask wicketstuff.org maintainers to update the examples deployed at this machine to latest 1.4.10 and 1.5-M1 versions. Recently we had a ticket about broken 1.4 examples but everything was fine in the latest snapshot (running the examples locally). Do you think it is a good idea to run the examples in DEVELOPMENT mode so we and the users can see the problem in the browser instead of asking for logs ? martin-g
Re: Form.delegateSubmit: invoke onSubmit() of nested Forms before onSubmit() of enclosing Form
i think this change was triggered by the commit for: WICKET-1124: enhancement of nested form handling its like that in the patch we got, i guess the patch is just applied this way. On Thu, Aug 5, 2010 at 12:38, Florian Wunderlich fwunderl...@factor3.de wrote: It can be assumed that an enclosing Form in some way or another may depend on the state of an enclosed Form, but that an enclosed Form should never depend on the state of its enclosing Form. Therefore, Form.delegateSubmit should invoke onSubmit() of the nested Forms (lines 1540-1553 in Form.java) before invoking onSubmit() of the enclosing Form (lines 1537-1538). Is there any reason why this is the other way around at the moment?
Re: Build Wicket 1.4.10 soon?
a very old java 5 version?? Java version: 1.5.0_06 thats old.. On Tue, Aug 10, 2010 at 18:56, Martin Grigorov mgrigo...@apache.org wrote: I still don't understand why only Igor had these problems. On Tue, Aug 10, 2010 at 6:50 PM, Jeremy Thomerson jer...@wickettraining.com wrote: Nevermind - just saw commits 983268 and 983292. On Tue, Aug 10, 2010 at 11:48 AM, Jeremy Thomerson jer...@wickettraining.com wrote: So, what changed that it was able to build for you? On Sat, Aug 7, 2010 at 2:46 AM, Igor Vaynberg igor.vaynb...@gmail.com wrote: weird. compiles here with 6 but not with 5 :| i guess one of you guys will have to do the build. -igor On Sat, Aug 7, 2010 at 12:38 AM, Martin Grigorov mgrigo...@apache.org wrote: No errors here too with both jdk 1.5 and 1.6. On Sat, Aug 7, 2010 at 7:27 AM, Jeremy Thomerson jer...@wickettraining.comwrote: Well, on my laptop I have to regularly switch between 5 and 6, so there's really no telling. :) On Aug 7, 2010 12:24 AM, Igor Vaynberg igor.vaynb...@gmail.com wrote: but did you do it with jdk5? -igor On Fri, Aug 6, 2010 at 10:16 PM, Jeremy Thomerson jer...@wickettraining.com wrote: That's weird... -- Jeremy Thomerson http://www.wickettraining.com -- Jeremy Thomerson http://www.wickettraining.com
Re: [vote] release wicket 1.4.10
+1 On Sat, Aug 7, 2010 at 20:23, Igor Vaynberg igor.vaynb...@gmail.com wrote: This vote is to release wicket 1.4.10 Branch: http://svn.apache.org/repos/asf/wicket/branches/wicket-1.4.10/ Artifacts: http://people.apache.org/~ivaynberg/wicket-1.4.10/dist Maven repo: http://people.apache.org/~ivaynberg/wicket-1.4.10/m2-repo Changelog: https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=truemode=hidesorter/order=DESCsorter/field=prioritypid=12310561fixfor=12315070 This vote ends Tuesday 12:00 GMT-8 Please test the release and offer your vote: [ ] Yes, release [ ] No, don't release it (and please tell us why)
Re: remove oninitialize/onconfigure from 1.4.x?
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?
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?
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?
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: Wicket stuff server maintenance
Why do we want already tomcat 7, which is still in a first? beta? Why not the latest stable 6? Is it really faster and better? (I havent really looked into 7 yet will do asap) - Original message - OK seems to be a tomcat 7 incompatibility of hudson... Martijn On Wed, Jul 21, 2010 at 10:46 PM, Martijn Dashorst martijn.dasho...@gmail.com wrote: installing hudson 1.367 doesn't seem to work properly. I get 404 errors on the homepage, users page and other pages. Asking around on #hudson on irc hasn't yielded a response... Martijn On Wed, Jul 21, 2010 at 6:24 PM, Martijn Dashorst martijn.dasho...@gmail.com wrote: As you might have noticed, I've done a bit of preparing for our migration to hudson... Tomcat - 7.0 Java - 1.6 (otherwise tomcat doesn't run) I had to tweak the tomcat configuration to ensure that confluence would start up: added the missing drivers from the previous tomcat installation's lib folder, and fixed some startup parameters in catalina.sh Next: installing hudson. Martijn -- 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 -- 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: [proposal] Replace TeamCity on wicketstuff.org with Hudson for building wicketstuff projects
hudson is just a war right? so that can be dumped by anybody of the wicket devs to onto the tomcat webapp dir. What more does hudson need? On Wed, Jul 21, 2010 at 11:14, Martijn Dashorst martijn.dasho...@gmail.com wrote: My little bird told me that no build server is part of the new deal which is slated to be announced mid-august, so IMO we should not delay the migration off of teamcity and setup hudson. I'll contact the sysadmin for the box to see if I can grant direct access, or that only trusted folks are allowed. Martijn On Wed, Jul 21, 2010 at 9:43 AM, Martijn Dashorst martijn.dasho...@gmail.com wrote: There are some developments unfolding in the near future that might help out on the future of our wicketstuff server and/or its infrastructure. I don't have the full details to those plans yet, and don't know if they entail a build server of some sorts. I'm perfectly happy with switching to hudson—we use it at work and it has been a godsend compared to the other available solutions (though I still don't like the UI). I hope we can wait a (couple of) week(s) and see the future plans unfold to see what the details are, especially with respect to a build server. I'll ask around to see if it is part of that deal. Martijn On Wed, Jul 21, 2010 at 4:06 AM, Michael O'Cleirigh michael.ocleir...@rivulet.ca wrote: Hello, I've been using Hudson reliably to build wicketstuff core snapshot's and deploying them into the sonatype maven repository. I put together an older machine for this purpose (P4 1.8Ghz) and while it worked at first recently there have been memory issues (at least one of the DDR1 DIMM's is bad and the JVM keeps crashing). I have the builds running temporarily somewhere else but the long term solution is to run Hudson on a box that can be opened up to the other wicketstuff developers. My proposal is to replace TeamCity on wicketstuff.org with Hudson and then do the necessary setup to allow wicketstuff developers access to it for initiating builds and viewing the projects status. I am willing to do all of the necessary setup and configuration to make this happen; basically copying over what I have working right now plus adding in user authentication. The easiest way would be if I could get a user account on the wicketstuff.org server (at least initially) and then get everything setup. There are still some questions around if the wicketstuff.org box is still banned by sourceforge but I think the best way to find out the answer is to try and see what happens. Regards, Mike -- 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: [proposal] Replace TeamCity on wicketstuff.org with Hudson for building wicketstuff projects
how do you deploy then? has hudson its container (tomcat)?? Then we also need another port. And have all kind of apache config to support things like: wicketstuff.org/hudson hmm that i dont like. It should just run on the tomcat instance we have. On Wed, Jul 21, 2010 at 14:51, Martijn Dashorst martijn.dasho...@gmail.com wrote: Security needs to be enabled and other stuff. Deploying as a war does have some drawbacks: restarting using the UI won't work, installing/updating plugins/new versions of hudson is enabled by default. Martijn On Wed, Jul 21, 2010 at 2:46 PM, Johan Compagner jcompag...@gmail.com wrote: hudson is just a war right? so that can be dumped by anybody of the wicket devs to onto the tomcat webapp dir. What more does hudson need? On Wed, Jul 21, 2010 at 11:14, Martijn Dashorst martijn.dasho...@gmail.com wrote: My little bird told me that no build server is part of the new deal which is slated to be announced mid-august, so IMO we should not delay the migration off of teamcity and setup hudson. I'll contact the sysadmin for the box to see if I can grant direct access, or that only trusted folks are allowed. Martijn On Wed, Jul 21, 2010 at 9:43 AM, Martijn Dashorst martijn.dasho...@gmail.com wrote: There are some developments unfolding in the near future that might help out on the future of our wicketstuff server and/or its infrastructure. I don't have the full details to those plans yet, and don't know if they entail a build server of some sorts. I'm perfectly happy with switching to hudson—we use it at work and it has been a godsend compared to the other available solutions (though I still don't like the UI). I hope we can wait a (couple of) week(s) and see the future plans unfold to see what the details are, especially with respect to a build server. I'll ask around to see if it is part of that deal. Martijn On Wed, Jul 21, 2010 at 4:06 AM, Michael O'Cleirigh michael.ocleir...@rivulet.ca wrote: Hello, I've been using Hudson reliably to build wicketstuff core snapshot's and deploying them into the sonatype maven repository. I put together an older machine for this purpose (P4 1.8Ghz) and while it worked at first recently there have been memory issues (at least one of the DDR1 DIMM's is bad and the JVM keeps crashing). I have the builds running temporarily somewhere else but the long term solution is to run Hudson on a box that can be opened up to the other wicketstuff developers. My proposal is to replace TeamCity on wicketstuff.org with Hudson and then do the necessary setup to allow wicketstuff developers access to it for initiating builds and viewing the projects status. I am willing to do all of the necessary setup and configuration to make this happen; basically copying over what I have working right now plus adding in user authentication. The easiest way would be if I could get a user account on the wicketstuff.org server (at least initially) and then get everything setup. There are still some questions around if the wicketstuff.org box is still banned by sourceforge but I think the best way to find out the answer is to try and see what happens. Regards, Mike -- 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 -- 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: [proposal] Replace TeamCity on wicketstuff.org with Hudson for building wicketstuff projects
its a FreeBSD server, so dont know if that is all the same that a linux one. But still everywhere i see java -jar hudson.war or hudson start That means that hudson has its own web container right? Where does that run on? which port? Then again also changes to apache must be done to map http://wicketstuff.org/hudson to localhost:HUDSONPORT/ so i rather have it just running inside the webcontainer we already have. On Wed, Jul 21, 2010 at 15:28, James Carman ja...@carmanconsulting.com wrote: Here are the instructions for setting it up on linux/unix: http://wiki.hudson-ci.org/display/HUDSON/Installing+Hudson#InstallingHudson-Unix%2FLinuxInstallation You *can* just do: java -jar hudson.war and it'll run. That's just a quick way to get it up and running to play around with it. On Wed, Jul 21, 2010 at 9:11 AM, Johan Compagner jcompag...@gmail.com wrote: how do you deploy then? has hudson its container (tomcat)?? Then we also need another port. And have all kind of apache config to support things like: wicketstuff.org/hudson hmm that i dont like. It should just run on the tomcat instance we have. On Wed, Jul 21, 2010 at 14:51, Martijn Dashorst martijn.dasho...@gmail.com wrote: Security needs to be enabled and other stuff. Deploying as a war does have some drawbacks: restarting using the UI won't work, installing/updating plugins/new versions of hudson is enabled by default. Martijn On Wed, Jul 21, 2010 at 2:46 PM, Johan Compagner jcompag...@gmail.com wrote: hudson is just a war right? so that can be dumped by anybody of the wicket devs to onto the tomcat webapp dir. What more does hudson need? On Wed, Jul 21, 2010 at 11:14, Martijn Dashorst martijn.dasho...@gmail.com wrote: My little bird told me that no build server is part of the new deal which is slated to be announced mid-august, so IMO we should not delay the migration off of teamcity and setup hudson. I'll contact the sysadmin for the box to see if I can grant direct access, or that only trusted folks are allowed. Martijn On Wed, Jul 21, 2010 at 9:43 AM, Martijn Dashorst martijn.dasho...@gmail.com wrote: There are some developments unfolding in the near future that might help out on the future of our wicketstuff server and/or its infrastructure. I don't have the full details to those plans yet, and don't know if they entail a build server of some sorts. I'm perfectly happy with switching to hudson—we use it at work and it has been a godsend compared to the other available solutions (though I still don't like the UI). I hope we can wait a (couple of) week(s) and see the future plans unfold to see what the details are, especially with respect to a build server. I'll ask around to see if it is part of that deal. Martijn On Wed, Jul 21, 2010 at 4:06 AM, Michael O'Cleirigh michael.ocleir...@rivulet.ca wrote: Hello, I've been using Hudson reliably to build wicketstuff core snapshot's and deploying them into the sonatype maven repository. I put together an older machine for this purpose (P4 1.8Ghz) and while it worked at first recently there have been memory issues (at least one of the DDR1 DIMM's is bad and the JVM keeps crashing). I have the builds running temporarily somewhere else but the long term solution is to run Hudson on a box that can be opened up to the other wicketstuff developers. My proposal is to replace TeamCity on wicketstuff.org with Hudson and then do the necessary setup to allow wicketstuff developers access to it for initiating builds and viewing the projects status. I am willing to do all of the necessary setup and configuration to make this happen; basically copying over what I have working right now plus adding in user authentication. The easiest way would be if I could get a user account on the wicketstuff.org server (at least initially) and then get everything setup. There are still some questions around if the wicketstuff.org box is still banned by sourceforge but I think the best way to find out the answer is to try and see what happens. Regards, Mike -- 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 -- 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: [vote] Revert WICKET-2846
+1 revert it, i dont see a big pro in having it anyway On Sat, May 22, 2010 at 09:22, Jeremy Thomerson jer...@wickettraining.comwrote: As you may have noticed over the past couple of days (ha), there has been quite a bit of discussion over what seemed at the time like a very trivial change in WICKET-2846 [*]. The end result is that it does not break any existing applications that don't already have a bug. However, if the application is already faulty in the way it uses threads (perhaps even due to a bug within Java related to cleaning up Java2D threads), then the change in WICKET-2846 can exacerbate the issue. On the flip side, the enhancement in WICKET-2846 is of very minor value to only a very small subset of cases that should rarely be used since they would not be considered best practices. And, if it were reverted, there would be fairly easy ways to get the same functionality without this change. So, I leave it to the community to vote on this. Because I feel neither +1 or -1 on this issue, my (binding) vote will go to whatever non-binding majority wins. So, in this case, *every vote counts* - even if your vote is typically non-binding. As one last comment, please: we don't need any more long-running discussions or diatribes on this. We already know this issue intimately. Please simply vote, and if you must, provide a simple reason why you're voting the way you are. [ ] +1 - revert WICKET-2846 in the next release (in other words, get rid of the InheritableThreadLocal) [ ] -1 - leave everything exactly as it is (in other words, keep the InheritableThreadLocal) [*] - https://issues.apache.org/jira/browse/WICKET-2846 Best regards, -- Jeremy Thomerson http://www.wickettraining.com
Re: [vote] Release Wicket 1.4.9
+1 (i dont care about the InheritableThreadLocal, if there are really problems with it we could back it out in the next release) On Wed, May 19, 2010 at 09:35, Jeremy Thomerson jer...@wickettraining.comwrote: This vote is to release wicket 1.4.9 Branch: http://svn.apache.org/repos/asf/wicket/branches/wicket-1.4.9/ Artifacts: http://people.apache.org/~jrthomerson/releases/apache-wicket-1.4.9/dist Maven repo: http://people.apache.org/~jrthomerson/releases/apache-wicket-1.4.9/m2-repo Changelog: https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310561styleName=Htmlversion=12314962 (and below) This vote ends Saturday 2:30am GMT-5 Please test the release and offer your vote: [ ] Yes, release [ ] No, don't release it (and please tell us why) -- Jeremy Thomerson http://www.wickettraining.com - Release Notes - Wicket - Version 1.4.9 ** Bug * [WICKET-2741] - non-performant Collections.synchronizedMap() should be replaced with ConcurrentMap * [WICKET-2843] - Palette is incompatible with ListMultipleChoice in its use of the model * [WICKET-2853] - ListMultipleChoice/CheckBoxMultipleChoice do not retain selected but disabled items * [WICKET-2856] - PackageStringResourceLoader.loadStringResource() causes NullPointerException when used in a Class within the root package (i.e. it has no package declaration) * [WICKET-2858] - WicketSessionFilter: java.lang.IllegalArgumentException: Argument application can not be null * [WICKET-2859] - Wrong package names in Examples * [WICKET-2860] - Wrong name for swiss Application.properties * [WICKET-2861] - getConvertedInput() returns null and selectedValues.addAll tries adding it ** Improvement * [WICKET-2790] - wicketTester.executeAjaxEvent method does not check if form is multiPart * [WICKET-2840] - Remove final on AbstractRequestTargetUrlCodingStrategy#getMountPath() * [WICKET-2846] - Store Application in InheritableThreadLocal instead of ThreadLocal * [WICKET-2855] - Constructor of RedirectRequestTarget does not validate URL * [WICKET-2869] - RangeValidator should use getMinimum and getMaximum * [WICKET-2870] - Fix hungarian translation for Wizard * [WICKET-2879] - delegate isVisible in PanelCachingTab
Re: [vote] Release Wicket 1.4.9
which leaks? give use a real wicket example where it leaks, which isnt the thread itself thats the leak. On Fri, May 21, 2010 at 12:49, Adriano dos Santos Fernandes adrian...@gmail.com wrote: On 20/05/2010 19:14, Jeremy Thomerson wrote: But it also don't break anything with the ITL, and it doesn't add more complexity. So, in that case, why should we remove the ITL? It was already shown various reasons where it doesn't work well: leaks due to *Java class library threads*; problem with multiple Wicket applications in same web application; problem with shareable classes creating threads. Don't try to generalize specific problems. Before, Wicket was always in favor of letting hooks for people do specific things, why do that evil change now? Adriano
Re: WICKET-2846 - Store Application in InheritableThreadLocal instead of ThreadLocal
i still dont see your solution about the wicket thread class.
What should that one do??? give an example.
The best solution is to use a threadpool like a described above.
And yes that InheritableThreadLocal isnt needed then.
But using
final Application app = Application.get()
// start thread
is exactly the same kind of leakage as using InheritableThreadLocal
On Thu, May 20, 2010 at 12:38, Adriano dos Santos Fernandes
adrian...@gmail.com wrote:
On 19/05/2010 22:29, Jeremy Thomerson wrote:
It solves this problem, which is specifically why it was requested:
onClickOrSomethingSimilar() {
new Thread(new Runnable() {
void run() {
doSomethingWith(Application.get());
}
}).start();
}
That's what I said about have a WicketThread class, or publish
Application.set/clear for users do this with more safety.
Adriano
Re: [vote] Release Wicket 1.4.9
Exactly...
the InheritableThreadLocal is never a problem, its the thread itself not
what it possess
in the other thread this example is given:
final Application application = Application.get();
new Thread(new Runnable()
{
run() {application.xxx}
}).start();
if that thread doesnt die on a redeploy, you have the exact same leak.
There is no difference what so ever. Its the thread/runnable object holding
on to a application instance.
But i dont mind if that InheritableThreadLocal is reverted, because i dont
see a big win in that anyway
starting new threads like above can be handled as above, but doing the above
thing or with InheritableThreadLocal is a bad design anyway
You shouldnt never just start threads for a request... Then it is so easy to
completely bomb out your server.. just hit that same request 1 times
Use pooling for that with a max number of threads doing what you want to
do..
If people would like we could introduce a getExecutor() in (Web)Application
and we handle the Application.set/unset for you in the Executor threads.
We could give you there options for a scheduled or none scheduled and so on.
Then creating threads on the fly isnt needed, there is no need to set the
application anywhere just use the wicket executor...
johan
On Wed, May 19, 2010 at 21:36, Juliano Viana juli...@logicstyle.com wrote:
Hi Adriano,
If your application creates (or uses a library that creates) threads that
don't die when the application is redeployed then you will have a memory
leak no matter what Wicket does.
If, on the other hand, all your theads are well behaved and die properly
when your application is redeployed, you have no memory leak even with
InheritableThreadLocal.
So using InheritableThreadLocal or not will not make any difference in this
case.
Regards,
- Juliano
On Wed, May 19, 2010 at 4:20 PM, Adriano dos Santos Fernandes
adrian...@gmail.com wrote:
On 19/05/2010 15:57, Jeremy Thomerson wrote:
Here's how you create a quickstart:
http://www.jeremythomerson.com/blog/2008/11/wicket-quickstart-tutorial/
If you find that there is a bug, you zip your quickstart directory and
attach it to a JIRA issue. Then we fix it and build a new release and
start
a new vote (if the bug is serious enough).
I know, I know... For example, the ones I have in Jira and got closed
without analyze, or the ones I attached with fixes.
I can't, however, do it now. But I would have no reason to do it knowing
some folks just consider a normal thing restart the container to update
the
application. So if Wicket devs are in this way, I could write no
quickstart
to convince.
Guice, by its use of thread locals, and considering that Java thread
locals
are not ideal, have the same type of bug. They could solve it with an API
to
close a thing, but they don't. They could ship some fancy classes that
may
work (accordingly to old @crazybob says) in some cases but they also
didn't.
So if you redeploy an app with Guice in Tomcat, it logs about a thread
local
leak.
It's going to do the same thing with Wicket.
Adriano
Re: WICKET-2846 - Store Application in InheritableThreadLocal instead of ThreadLocal
- Original message - On 19/05/2010 13:06, Alex Objelean wrote: This currently make web-classloader leaks. If you start using InheritableThreadLocal's with arbitrary objects, you're going to make even more leaks. Also note, there is something not good here. AFAIK, Wicket sets the thread locals only during the request. But if child threads are spawned, they can't be cleaned automatically. IMO, it should be done something that the user needs to call to set/clear this, like a specialized WicketThread class. And when should that one clean up the threadlocal?? What would be a good time to clean it up? There would only be 1 place thats when then run method is finished. But if thats the case the thread and the threadlocals are cleared any way. if you would use a thread pool then you have to use otherways any way to se the Application threadlocal. Thread pools have call backs when a runnable is being executed and finished. But threads that are created in a request should finish and terminate at one point and never be reused.
Re: WICKET-2846 - Store Application in InheritableThreadLocal instead of ThreadLocal
If you where using threads in your application
Then i would do it this way:
Your WebApplication class has a method:
getExecutor() that returns a ThreadPoolExecutor
That threadpoolexecutor (that you extend) overrides 2 methods
protected void beforeExecute(Thread t, Runnable r) { }
that sets the thread locals (so the application instance that has the
executor) and
protected void afterExecute(Runnable r, Throwable t) { }
to release all thread locals.
this way you use a pool (way better to control your web application) and all
the resources you need are set just before and release right after.
johanm
On Wed, May 19, 2010 at 23:41, James Carman ja...@carmanconsulting.comwrote:
Will the inheritance of the application really work correctly? For pooled
threads that are created at application startup, the threadlocal will be
null, because the parent thread is the thread that starts the container.
For threads that are created within the context of the request thread, they
will get the current application object, which would be fine if that thread
executes and finishes. But, for threads that are going to be reused
(executor threads in a pool), they will see the original application object
because the value is set at thread creation time. If you have multiple
wicket filters in the same context, that could be incorrect, meaning a
request thread for a different application submitted a task to be executed.
On May 19, 2010 4:13 PM, Adriano dos Santos Fernandes
adrian...@gmail.com
wrote:
On 19/05/2010 17:03, Jeremy Thomerson wrote:
To clarify this, I use Application.set and App...
Well, forgetting to unset it would not leak any more than have it
implicitly
set like it's going to be. And I do think forgetting this is developer
fault.
What you all do not want to understand is what I said about Java library
spawning its own threads, and that is not documented, as its for cleanup in
the case I shown.
Adriano
Re: [vote] release wicket 1.4.8
I checked today 2 little things in that i would like to have in the next build one of this is a small regression from: WICKET-1825 The other is a small fix for the patch that i did yesterday for modal window. On Mon, Apr 26, 2010 at 19:12, Igor Vaynberg igor.vaynb...@gmail.comwrote: this vote is to release wicket 1.4.8 this maintenance release brings over 20 bug fixes and improvements. branch: https://svn.apache.org/repos/asf/wicket/branches/wicket-1.4.8/ artifacts: http://people.apache.org/~ivaynberg/wicket-1.4.8/http://people.apache.org/%7Eivaynberg/wicket-1.4.8/ changelog: https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=truepid=12310561fixfor=12314811 (and below) vote ends Thursday 11am gmt-8 cheers -igor Release Notes - Wicket - Version 1.4.8 ** Bug * [WICKET-2075] - Pagemap is locked forever with some Page serialization exceptions * [WICKET-2424] - OnChangeAjaxBehavior + DatePicker do not work together * [WICKET-2764] - MarkupCache messed up when using MergedMarkup (e.g. for Page markup inheritance) together with IResourceStreams that do NOT also implement IFixedLocationResourceStream * [WICKET-2767] - DatePicker Calendar: wrong year format when 4 digits are used (), e.g. 2010 -- 0010 * [WICKET-2772] - Generate wicketpath attribute for RadioChoice * [WICKET-2779] - Submit a nested form via ajax to upload a file inside modal window does not work on IE. * [WICKET-2787] - ValueMap.getAsBoolean(key, defaultValue) always returns false for non-existing keys, instead of the defaultValue * [WICKET-2799] - @RequireHttps not switching to https when setting response page to non-bookmarkable page * [WICKET-2802] - StringIndexOutOfBoundsException in PortletServletRequestWrapper for some resource requests * [WICKET-2806] - Javascript looking for related radio in group is not working if css class is already assigned to radio * [WICKET-2822] - Small Bug in JavaDoc for SpringWebApplicationFactory ** Improvement * [WICKET-2771] - Please support isPrimary for @SpringBean * [WICKET-2776] - Enhancing RadioChoice input items with individual title and css class attributes * [WICKET-2778] - Set Application ThreadLocal in WicketSessionFilter * [WICKET-2796] - Improve error reporting on locked page maps * [WICKET-2803] - ListMultipleChoice's Constructors Should Accept IModel? extends CollectionT * [WICKET-2813] - IndicatingAjaxButton should have construtors that take a IModel for the button text as does AjaxButton. * [WICKET-2817] - ChoiceGroup's Constructor Should Accept IModel? extends CollectionT * [WICKET-2821] - More IModel? extends Collection Fixes * [WICKET-2830] - Make BookmarkablePageRequestTargetUrlCodingStrategy#encode non final * [WICKET-2831] - ConverterLocator#get(ClassT) shouldn't be final * [WICKET-2837] - Inaccurate AjaxSubmitLink Javadoc ** Wish * [WICKET-2847] - Make StringResourceStream non final
Re: Future of wicketstuff.org
problem is that we need to roll those var logs better. With those latest maven fixes for this unique version number problems did fix most of the hd problems only var is now an issue because of those logs that are just appending and appending. that will not solve even if we just host the examples because that is the problem i think. (apache and or tomcat logs) So first if somebody could look once at those logs then i think many of those maintenance issues are gone i dont think that /repository/maven and so on is now a problem with diskspace. On Mon, Apr 19, 2010 at 17:31, Martijn Dashorst martijn.dasho...@gmail.comwrote: Currently we have a maintenance nightmare. Keeping up confluence, jira, teamcity and the maven repo is cumbersome at best. We keep running out of diskspace (/var has reached -300M disk free, yes minus 300M). So I propose the following: - use Apache's build grid for Wicket code, Apache repository for staging and snapshot releases: separating the Apache Wicket projects from Wicket Stuff projects - no more custom, self hosted products a la confluence and jira (no matter how much we like them) - use wicketstuff.org only for running examples and a build server for wicket stuff projects - use sonatype's OSS repo hosting for our snapshots, release staging and releases (no more wicketstuff.org/repository/maven) Most importantly: - vote on the future of the hosting of Wicket Stuff: [ ] stay with sf.net [ ] move to github - if we stay on sf.net: use the sf.net provided tools to manage the project: issues, wiki and website - if we stay to move to github: use github's provided tools to manage the project: issues, wiki and website Martijn
Re: Wicket stuff disk usages
i cleaned out /var will talk to seb to just kill those stupid mod_jk logs and httpd-access i just deleted some log files and now on 22% is used... On Mon, Apr 19, 2010 at 16:45, Martijn Dashorst martijn.dasho...@gmail.comwrote: The volume says it's out of diskspace. The following usages are recorded: 0BTeamCity 3.1Mapache-maven-2.2.1 6.8Gapache-tomcat-6.0.20 50Matlassian-jira-enterprise-3.12.3 49Matlassian-jira-standard-3.12.3 4.0Kautomation.asp 2.0Kbin 2.0Kconflience-spam.txt 76Mconfluence-2.8.0 486Mdownloads 2.0Kid_rsa.pub 2.0Kjrthomerson-ssh-key.pub 24Mmaven 0Bmvn 2.0Kn09230945.asp 1.1Gteamcity-4.0 1.9Gteamcity-5.0 836Mtmp 0Btomcat 36Gvar 177Mwscore-build-dir
Re: Git migration for stuff
no integration needed? How do you compare (with the repository version or another version, branch)? how do you check what is all incoming? (synchronize with working sets) History view: getting a revision, comparing 2 revisions, getting the contents? Annotations? I use above points daily. I cant do without it. johan On Thu, Mar 4, 2010 at 22:10, Antony Stubbs antony.stu...@gmail.com wrote: Like the man said, the eclipse support ain't too bad. But the way Git works you really don't _need_ integration. If you want a good ui there's Tortoise Git for windows or GitX for OSX. git-svn is useful, but limits you. It's very slow and cannot support merges (because it has to eventually fall back to SVN representation). jcompagner-2 wrote: How is the latest eclipse plugin support? But why not just use then svn-git 'bridge' that git has build in? - Original message - What's the latest on Git migration? If not for Wicket proper, for Wicket-Stuff? Windows support as come a long way... - ___ http://stubbisms.wordpress.com http://stubbisms.wordpress.com -- View this message in context: http://old.nabble.com/Git-migration-for-stuff-tp27774047p27786581.html Sent from the Wicket - Dev mailing list archive at Nabble.com.
Re: Git migration for stuff
How is the latest eclipse plugin support? But why not just use then svn-git 'bridge' that git has build in? - Original message - What's the latest on Git migration? If not for Wicket proper, for Wicket-Stuff? Windows support as come a long way...
Re: Igor did it!
Whoohooo finally i get rid of all the spam messages! On Tue, Mar 2, 2010 at 12:40, Matej Knopp matej.kn...@gmail.com wrote: All tests in Wicket Trunk pass (except that one ignored, whatever that is). Kudos to Igor! -Matej
Re: [vote] release wicket 1.4.7
+1 On Mon, Mar 1, 2010 at 01:13, Igor Vaynberg igor.vaynb...@gmail.com wrote: this vote is to release wicket 1.4.7 this maintenance release brings over 30 bug fixes and improvements. branch: https://svn.apache.org/repos/asf/wicket/branches/wicket-1.4.7/ artifacts: http://people.apache.org/~ivaynberg/wicket-1.4.7/http://people.apache.org/%7Eivaynberg/wicket-1.4.7/ (currently uploading...) changelog: https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=truepid=12310561fixfor=12314560 (and below) vote ends Wednesday 5pm gmt-8 cheers -igor Release Notes - Wicket - Version 1.4.7 ** Bug * [WICKET-2510] - Radio getMarkupId not working correctly * [WICKET-2615] - URL mismatch with RENDER_TO_BUFFER when URL rewriting features of container are used * [WICKET-2648] - DatePicker javascript uses 4 symbols for year although pattern contains just yy * [WICKET-2657] - Multipart forms fails on Chrome during Ajax submit * [WICKET-2660] - Wickettester executeAllTimerBehaviors executes stopped behaviors too * [WICKET-2663] - Modal Dialog cannot add AjaxLink when UploadWebRequest is in use * [WICKET-2688] - Versioned form with FileUploadField will expire page if you submit the form twice. * [WICKET-2702] - update PropertyColumn Javadoc * [WICKET-2704] - FormComponent.MessageSource.getMessage(String) and getValidatorKeyPrefix() * [WICKET-2714] - SharedResourceRequestTarget sets Status 404 when not found, ignoring any 404 settings * [WICKET-2715] - AuthenticatedWebSession in wicket-auth-roles does thread-unsafe access to signedIn boolean * [WICKET-2717] - bookmarkablepagelink broken on ajaxupdate * [WICKET-2718] - RedirectPage does not work in IE * [WICKET-2721] - IE does not display ExceptionErrorPage * [WICKET-2726] - CLONE -Ajax multipart broken on mounted pages * [WICKET-2734] - Form#anyComponentError change in 1.4 breaks validation * [WICKET-2738] - setResponsePage doesn't work with MixedParamUrlCodingStrategy * [WICKET-2740] - DynamicWizardModel: setActiveStep is called twice * [WICKET-2744] - AjaxFormChoiceComponentUpdatingBehavior cannot find the choice * [WICKET-2749] - multipart form does not call window.wicketGlobalPreCallHandler * [WICKET-2753] - Javascript in Form.registerJavascriptNamespaces() fails in Firefox 3.5.8 * [WICKET-2757] - MimeType/ContentType detection in ResourceStreamRequestTarget unreliable * [WICKET-2759] - libxml2 splits large CData section. this breaks the processing of components ** Improvement * [WICKET-2661] - Palette does not allow tracking the AbstractChoices components via Ajax * [WICKET-2698] - Page Parameters needs to implement equals * [WICKET-2706] - French translations for missing properties * [WICKET-2708] - Extend SwitchProtocolRequestTarget so it's possible to customize the redirect url * [WICKET-2709] - EmptySrcAttributeCheckFilter should check for src=# * [WICKET-2719] - Extract lazy AbstractListDataProvider out of ListDataProvider. * [WICKET-2720] - Panel throws MarkupException without passing MarkupStream * [WICKET-2731] - provide hook to enforce fqn's leaking out from shared resources * [WICKET-2737] - reduce number of SpringBeanLocator#getBeanNameOfClass calls. * [WICKET-2748] - IE6 sometimes fails when using wicket ajax * [WICKET-2750] - Better error handling in modal window setContent() when a repeater is used
Re: Doubt about form components
if a user refreshes the browser or does some other action (go first to another form in another page and back again) then we still can render the latest user output just fine the next time On Mon, Feb 22, 2010 at 21:42, Pedro Santos pedros...@gmail.com wrote: IMO the form processing can be: 1. validate 2. detect error 3. keep rawinput 4. re-render error components with red border AND rawinput 4.1. throw away the raw input in some detach method 5. user retry form submit 6. all form components get they raw input again since they get rendered before some detach method clear they raw input, no need to maintain those values on the server -- Pedro Henrique Oliveira dos Santos
Re: [vote] release wicket 1.4.6
+1 On Tue, Jan 26, 2010 at 08:42, Igor Vaynberg igor.vaynb...@gmail.comwrote: this vote is to release wicket 1.4.6 this maintenance release brings over 40 bug fixes and improvements. branch: https://svn.apache.org/repos/asf/wicket/branches/wicket-1.4.6/ artifacts: http://people.apache.org/~ivaynberg/wicket-1.4.6/http://people.apache.org/%7Eivaynberg/wicket-1.4.6/ (currently uploading...) changelog: https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=truemode=hidesorter/order=DESCsorter/field=prioritypid=12310561fixfor=12314470 (and below) vote ends Friday 12am gmt-8 thank you. -igor Release Notes - Wicket - Version 1.4.6 ** Sub-task * [WICKET-2678] - isEnabled called in AjaxRequestTarget for Behaviors even if component is not Visible in hierarchy ** Bug * [WICKET-1825] - url-escaping is not undone for requestcodingstrategy * [WICKET-2312] - RequestUtils.toAbsolutePath() not output hostname and url-pattern in AJAX * [WICKET-2567] - Images and stylesheets leave open file handles * [WICKET-2616] - BaseWicketTester chooses a disabled component as the source of an AjaxFormSubmit event * [WICKET-2619] - wicket should handle Enums like other primitives when injecting them. * [WICKET-2620] - DataTable generates two thead wicket:id=topToolbars * [WICKET-2624] - MethodGetAndSet.setValue uses wrong source to determine which type to convert to when there's no setter * [WICKET-2629] - HttpsRequestCycleProcessor causes HttpSession to be created * [WICKET-2630] - MockHttpServletResponse doesn't delete cookies * [WICKET-2633] - AjaxEditableLabel fails to focus editor upon validation errors * [WICKET-2635] - Sucessfull login on SignInPanel causes HomePage to become stateful * [WICKET-2638] - Form.isMultipart() doesn't check FormComponent.isMultipart() on nested components * [WICKET-2639] - More pages missing xml prolog * [WICKET-2641] - EnumLabel misbehaves with anonymous enum * [WICKET-2645] - Resources aren't gziped by default * [WICKET-2647] - InspectorPage (from devutils) is stateful for no valid reason * [WICKET-2650] - Consistently create body for short tags. * [WICKET-2655] - WicketTester javadocs are referring in many places to a component's path but it's not documented anywhere * [WICKET-2666] - ConvererLocator.convertToString discards original cause of conversion failure * [WICKET-2667] - When multipart on form is set to true, setResponsePage() doesnt work * [WICKET-2668] - UploadProgressBar component can't be removed or replaced easily * [WICKET-2669] - DataTable mutiple bottom toolbars are misplaced because of bad html * [WICKET-2671] - Enclosure causes Nullpointer exception * [WICKET-2672] - FormComponent doesn't properly handle array model types * [WICKET-2675] - CryptedUrlWebRequestCodingStrategy fails in form with method=get * [WICKET-2679] - checkRendering() throws Exception if TransparentResolver is invisible * [WICKET-2685] - MixedParamsUrlCodingStrategy ,classcastexception from Long to String * [WICKET-2686] - CryptedUrlWebRequestCodingStrategy fails in form with method=get - 1.5 * [WICKET-2692] - DropDownChoice value may be lost after ajax submit call ** Improvement * [WICKET-2591] - Allow subclasses of AuthenticatedWebSession to set signedIn field * [WICKET-2626] - Make DatePicker on DateTimeField overrideable * [WICKET-2628] - SerializingObjectSizeOfStrategy should warn when unable to serialize the object * [WICKET-2637] - Lithuanian translation for the Application.properties * [WICKET-2642] - Russian translation of SignInPage/SignInPanel * [WICKET-2644] - Hungarian translation for wizard * [WICKET-2646] - Better error reporting from StatelessChecker * [WICKET-2649] - Make SignInPage stateless * [WICKET-2653] - Make GoAndClearFilter.defaultClearModel and GoFilter.defaultGoModel internationalizable * [WICKET-2656] - Ability to add CSS style to table body in DataTable * [WICKET-2664] - CheckBoxMultipleChoice should use isEnabledInHierarchy() * [WICKET-2673] - TabbedPanel not generic * [WICKET-2682] - Maven 3 produces various warnings ** Task * [WICKET-2670] - Remove deprecated API calls from wicket-extensions
Re: wicket 1.5 build is failing because of 1.6 deps...
that would be weird. if wicket 1.3 to wicket 1.4 would be just a .1 increase because of java 4 to 5 but because of java 6 we suddenly have to call it wicket 2.0? purely looking at the java version used wicket 1.3 to 1.4 is a way bigger leap then wicket 1.4 to 1.5 (looking at the changes wicket did for using the new features of java 5) Ofcourse maybe there are loads of other changes that would recommend a bigger version jump But the upgrade of a java version from 5 to 6 isnt one of them On Tue, Dec 29, 2009 at 12:47, Olivier Croisier olivier.crois...@gmail.comwrote: Then I'd suggest renaming Wicket 1.6 to Wicket 2.0, for the psychological impact, and to state clearly that this is a break in Wicket development. As for Java 1.5 vs 1.6, companies upgraded to 1.5 because it came with a huge lot of new features and improvements that their architects felt could help building better apps frameworks. On the other hand, Java 1.6 is often considered as a mere patch over 1.5 with no real value added, so many companies didn't bother upgrading and are waiting for 1.7 and its new features (closures, etc.). If it were only for me, I'd upgrade to the latest Java version anyday - but this is market reality. On Tue, Dec 29, 2009 at 1:55 AM, Ryan McKinley ryan...@gmail.com wrote: we can try to avoid it for some time if possible, but if some stuff as nicer for the core then i am against a separate jar and ugly build system +1 for 1.6 In my opinion, giving people more reasons to use a newer JVM is better (as if speed were not enough) Seems a shame to futz with a strange build to support people who are unable to upgrade in general. If someone is in an environment where they can't upgrade JVM from 1.5 - 1.6 (in late 2010), then seems odd they are allowed to upgrade to a new wicket version. ryan
