Thank you for the various responses regarding this issue. Pleased to tell you that testing results indicate the Wicket 1.2.4 patch has fixed our problems with concurrency without introducing any other known bugs! Big relief so thank you for this.
Regarding ongoing support for Wicket 1.3 and JDK 1.4, I've shared this information internally. It was helpful to get clarification and we can understand the stance taken to press ahead with Java 1.5. Change is inevitable, however multi-billion dollar industries, and corporations already invested in particular products may be slower to follow suit so we are hoping there will be enough interest to continue supporting Wicket 1.3 for some time to come. Be interested to know of any other users out there on projects where they'll be sticking with wicket 1.3 for foreseeable future? Anyhow, I've forwarded on this email thread to the other developers with regards to contributing to Wicket and hopefully some will take an interest. As one example where we may have something of use (for extensions ?), we've built our Wicket app based upon Service Data Object (SDO) technology as model objects - this includes the creation of Wicket SDOModels that use XPath expressions to get/set underlying model object child nodes etc (makes extensive use of nestedModels). We've also extended Wicket models to act as result sinks for webservces (call) responses - hence the service call responses automatically update the Wicket components etc. Other SOA engagements considering using SDO technology can take some comfort in knowing this approach works v.well (in case not already a known solution). Cheers, Rich. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Martijn Dashorst Sent: 26 June 2007 12:30 To: wicket-user@lists.sourceforge.net Subject: [Maybe Spam] Re: [Wicket-user] Wicket 1.2.4 - Cross session concurrency issues On 6/26/07, Seldon, Richard <[EMAIL PROTECTED]> wrote: > Martijn - Thanks for your helpful email. The links to the issues list did > the trick regarding issues tracking. No problem, just trying to help out. > Server that would permit usage of Java 1.5. Depending upon IBM and its plans > for future releases, and buy in from our Company to adopt the future > releases and undertake such a migration - we must accept that we are > working with Java version 1.4. Personally, i wish we were in a position to > use 1.5 :( Any ideas then when that is slated to happen? The IBM move I mean? I sure hope it is not 2 years ahead! Probably Wicket moving to 1.5 is not your problem then, but more a stagnant product line of IBM. You are aware that JDK 6 has a supposed increase in performance out-of-the-box of about 30%? > Would the patch ( revision 529917 that specifically addresses the critical > bug in 1.2.4) suffice? Or are there other fixes included with 1.2.6 that > relate to a "security implication" fix? As above, a change of Wicket release > to our code base this close to go-live would rather be avoided if possible. I think that that patch is sufficient to fix the particular security related bug. > Are you saying that 1.3 supports Java 1.4 for all dot releases therein. Yes, for the projects residing in the JDK-1.4 subdirectory. We will not move projects based on jdk 1.4 to jdk 1.5 in Wicket 1.3 > As of Wicket 1.4 there will be a dependency upon 1.5. Again, just looking for > explicit response on this. Yes, but we may call that one 2.0. > Commercially, we are an example where usage of > 1.5 just is not viable. I believe the decision to go with 1.5 will currently > preclude a significant proportion of third party service vendors. I think the market is migrating to JDK 1.5, or has largely migrated to it already. However, Wicket 1.3 is good enough to be around until the migration has completed. > Specifically, for stake holders currently investing in Wicket as a viable > web framework on large scale development projects where Java 1.4 is the > officially supported version what is the position? You imply that such stake > holders can be assured that defects raised in 1.3 will be addressed in 1.3. I can't give assurance: the Wicket project is based on individuals. I can tell a story that would make things less threatening: our community is diverse (scattered across continents, making the bus factor less). There are several core people on the Brittish island, so you may be able to contract them more easily, or even coerce into providing support by supplying ample amounts of beer. And you can join the community. If you want you can strive to join the Wicket core: write documentation, create unit tests, fix issues, provide patches. We will notice that and eventually (possibly sooner than later) grant commit karma. Apache is a meritocracy: earn merit and get privileges. This way is open to anyone! You will become part of the community, so you will need to abide by its rules. > Does Apache provide such assurance? We understand that this assurance would > not necessarily include enhancements but only bug fixes. Apache does not provide assurance for fixing bugs. If you want assurance, then you'll either need to fix it yourself, or hire some third party to do so. Instead, Apache provides assurance of a healthy community. A healthy community typically assures that bugs are fixed :). Fixing bugs can only happen when relevant bug reports are submitted, and they will be fixed even more quickly when a reproducable testcase is provided. The best way to get something fixed is by providing a patch. Most of the core conttributors have projects running on Wicket 1.3. Some of them will move onward with newer Wicket versions, others will keep running on 1.3. Fixing bugs in 1.3 will be a priority, but we of course expect that the number of bugs for 1.3 will become less and less, just as happened with 1.2 and 1.1 before that. When 1.3 is the mainstream release, support for 1.2 will be limited to critical bugs only, and probably 1.2.7 will be the last release for that branch, unless something critical pops up. Support for any particular version is based on the interest of the community. If someone has an interest in providing it (because he wants to be nice, or has his own project running it, or because it helps the framework, or the community) then the release will be supported. One of the greatest examples of a community effort is Maven 1: the core team moved on to build maven 2, which is a complete rewrite. Several people wanted to keep supporting maven 1, and just released Maven 1.1. It took them long enough, but they got there. The same thing can happen with the JDK 1.4 version of Wicket. If enough people have an interest in providing new functionality for the project, then it can keep growing. Or else you can take a look at the retroweaver project to see how that helps in adopting JDK 1.5 code for your Java 1.4 based project. Martijn -- Wicket joins the Apache Software Foundation as Apache Wicket Join the wicket community at irc.freenode.net: ##wicket Wicket 1.2.6 contains a very important fix. Download Wicket now! http://wicketframework.org ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user This e-mail (and any attachments) may contain privileged and/or confidential information. If you are not the intended recipient please do not disclose, copy, distribute, disseminate or take any action in reliance on it. If you have received this message in error please reply and tell us and then delete it. Should you wish to communicate with us by e-mail we cannot guarantee the security of any data outside our own computer systems. For the protection of Legal & General's systems and staff, incoming emails will be automatically scanned. Any information contained in this message may be subject to applicable terms and conditions and must not be construed as giving investment advice within or outside the United Kingdom. The following companies are subsidiary companies of the Legal & General Group Plc which are authorised and regulated by the Financial Services Authority for advising and arranging the products shown: Legal & General Partnership Services Limited (insurance and mortgages), Legal & General Insurance Limited (insurance), Legal & General Assurance Society Limited (life assurance, pensions and investments), Legal & General Unit Trust Managers Limited and Legal & General Portfolio Management Services Limited (investments). They are registered in England under numbers shown. The registered office is Temple Court, 11 Queen Victoria Street, London EC4N 4TP. Legal & General Partnership Services Limited: 5045000 Legal & General Assurance Society Limited: 166055 Legal & General (Unit Trust Managers) Limited: 1009418 Legal & General (Portfolio Management Services) Limited: 2457525 Legal & General Insurance Limited: 423930 They are registered with the Financial Services Authority under numbers shown. You can check this at www.fsa.gov.uk/register Legal & General Partnership Services Limited: 300792 Legal & General Assurance Society Limited: 117659 Legal & General (Unit Trust Managers) Limited: 119273 Legal & General (Portfolio Management Services) Limited: 146786 Legal & General Insurance Limited: 202050 ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
