Menu
▾
▴
springframework-developer — Spring Framework developers list
You can subscribe to this list here.
| 2003 |
Jan
|
Feb
(55) |
Mar
(100) |
Apr
(203) |
May
(330) |
Jun
(190) |
Jul
(302) |
Aug
(323) |
Sep
(197) |
Oct
(245) |
Nov
(490) |
Dec
(330) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2004 |
Jan
(194) |
Feb
(400) |
Mar
(416) |
Apr
(415) |
May
(359) |
Jun
(381) |
Jul
(491) |
Aug
(311) |
Sep
(291) |
Oct
(273) |
Nov
(355) |
Dec
(266) |
| 2005 |
Jan
(306) |
Feb
(303) |
Mar
(520) |
Apr
(346) |
May
(255) |
Jun
(221) |
Jul
(171) |
Aug
(247) |
Sep
(147) |
Oct
(125) |
Nov
(165) |
Dec
(65) |
| 2006 |
Jan
(90) |
Feb
(53) |
Mar
(121) |
Apr
(103) |
May
(113) |
Jun
(103) |
Jul
(104) |
Aug
(67) |
Sep
(78) |
Oct
(82) |
Nov
(78) |
Dec
(70) |
| 2007 |
Jan
(77) |
Feb
(76) |
Mar
(63) |
Apr
(30) |
May
(47) |
Jun
(41) |
Jul
(44) |
Aug
(44) |
Sep
(49) |
Oct
(33) |
Nov
(25) |
Dec
(21) |
| 2008 |
Jan
(45) |
Feb
(13) |
Mar
(15) |
Apr
(12) |
May
(9) |
Jun
(33) |
Jul
(30) |
Aug
(7) |
Sep
(20) |
Oct
(17) |
Nov
(20) |
Dec
(10) |
| 2009 |
Jan
(8) |
Feb
(5) |
Mar
(12) |
Apr
(17) |
May
(19) |
Jun
(97) |
Jul
(77) |
Aug
(33) |
Sep
(24) |
Oct
(41) |
Nov
(16) |
Dec
(32) |
| 2010 |
Jan
(24) |
Feb
(14) |
Mar
(50) |
Apr
(71) |
May
(70) |
Jun
(64) |
Jul
(45) |
Aug
(62) |
Sep
(32) |
Oct
(4) |
Nov
(12) |
Dec
(2) |
| 2011 |
Jan
(1) |
Feb
(3) |
Mar
(4) |
Apr
(3) |
May
(6) |
Jun
(1) |
Jul
(4) |
Aug
(3) |
Sep
(4) |
Oct
(6) |
Nov
(3) |
Dec
(3) |
| 2012 |
Jan
(4) |
Feb
(8) |
Mar
(6) |
Apr
(10) |
May
(2) |
Jun
(3) |
Jul
(11) |
Aug
(10) |
Sep
(4) |
Oct
|
Nov
(1) |
Dec
(1) |
| 2013 |
Jan
(4) |
Feb
(1) |
Mar
(9) |
Apr
(1) |
May
(8) |
Jun
(2) |
Jul
(5) |
Aug
(2) |
Sep
|
Oct
(3) |
Nov
(10) |
Dec
(8) |
| 2014 |
Jan
(3) |
Feb
(12) |
Mar
(9) |
Apr
(12) |
May
(2) |
Jun
|
Jul
(3) |
Aug
(1) |
Sep
(1) |
Oct
(4) |
Nov
|
Dec
(2) |
| 2015 |
Jan
(1) |
Feb
(3) |
Mar
(4) |
Apr
(9) |
May
(2) |
Jun
(2) |
Jul
|
Aug
(2) |
Sep
(7) |
Oct
(9) |
Nov
(7) |
Dec
(9) |
| 2016 |
Jan
(7) |
Feb
(5) |
Mar
(5) |
Apr
(5) |
May
(8) |
Jun
(4) |
Jul
(5) |
Aug
(4) |
Sep
(6) |
Oct
(7) |
Nov
(2) |
Dec
(3) |
| 2017 |
Jan
(7) |
Feb
(8) |
Mar
(7) |
Apr
(3) |
May
(4) |
Jun
(3) |
Jul
(5) |
Aug
(8) |
Sep
(4) |
Oct
(2) |
Nov
(3) |
Dec
|
| 2018 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
|
| 2019 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(1) |
| 2021 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2022 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
| 2024 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
|
| 2025 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
(2) |
Aug
(5) |
Sep
(2) |
Oct
|
Nov
|
Dec
(1) |
| 2026 |
Jan
(1) |
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Rod J. <rod...@in...> - 2003-10-23 01:51:59
|
Darren > * The main goal as I understand it is to provide an application testing > sandbox - ie one that focuses on the usage of Spring and not on the Spring > classes or components themselves. In this way we hope to verify that changes > to Spring which are known not to break compilation or unit testing of Spring > itself, also can be shown not to break applications depending on it and/or > maintain backward compatibility. Yes > * While such tests may be more important as new releases approach, there > should be no impediment (time and machine resources notwithstanding) to > performing such tests nightly against CVS snapshots. Yes > * Tests should be repeatable and the results unambiguous. This *may* involve > writing specific new test applications that focus on these goals rather than > attempting to fit existing sample applications to the purpose which may have > more of a user-educational benefit, or which are harder to test in a regular > fashion. Yes, but it should be possible to add more apps to the suite as necessary. > * Results should be made public in a consistent, user-friendly format, > possibly via html and with mail notifications to the dev-list. Yes. Simple success or failure, and information about any failure. > > * Test applications should be capable of automated deployment and testing on > various J2EE server platforms. Yes. > i. Given that no-one is likely to come forward with a large array of high > powered hardware for our testing pleasure (but do feel free to correct me), > the tests will need to be distributable. We will probably be able to find a > semi-permanent home for testing Tomcat/JBOSS, but this is the only way we > will be able to test against many other server platforms - in particular the > heavyweight and expensive commercial ones. (SourceForge do have a WebSphere > box in their compile farm, but I think it may be difficult to run the sort of > tests we want to run there.) > > ii. With distributable tests running ad-hoc on donated server resources, it > may not be possible or desirable to operate tests that begin with clean > platform installs. In some cases, the platform install may simply be too > problematic to script anyway, even if time and resource permitted. How > critical is this as a requirement? Whilst certainly feasible on > Tomcat/JBOSS, I'd suggest that trashing and re-deploying the test apps on an > existing server install is the best we might get for WebLogic / WebSphere et > al. I agree. With JBoss/Tomcat I'd unzip it. Also Orion if we wanted to. I don't know much about WebSphere configuration. WebLogic has nice clean separate server config directories, so we should be able to handle it at that level. > iii. Each application server will require it's own script(s), perhaps even one > per test application per server. However, once a test application is > deployed, the actual test should be designed to be handled in a > server-agnostic manner unless deliberately testing specific platform > differences. Further investigation might show that something like custom ANT > tasks would be of use somewhere here. Good point. We need to choose a test tool. RMI is handy for EJB-based tests. Other stuff may need to be web tested via Latka or the like. Or we could deploy some test cases into the server. I'm not a big fan of things like Cactus in testing applications, but they may make sense for this kind of thing. We could have some tests outside any container of course. Like checking transactional behaviour via AOP against a database, and checking the results. > iv. Dependencies need careful consideration in how they may affect test > results given a widespread test environment. The database problem has > already been remarked upon, local dependencies such as db drivers, different > versions of libraries in the lib/ext (or equivalent) directory of the server > installation and even possibly different JDK versions are elements that will > have to be dealt with which wouldn't necessarily be issues in a testing lab. > It may be possible to report some of this information within the test results > where sensible values can be retreived. Does anyone have thoughts on this? We should be able to say which versions of a server we've tested on. E.g. WebLogic 8.1 SP1, JBoss 3.x.x. We can't guarantee users testing on every combination out there, but we should be able to say "that problem doesn't occur with certain combinations we've tested." > > v. Unambiguous results may be a goal too far. It may be that results will > have to be verified individually with someone deciding whether a 'failure' is > really a failure that we need to be concerned with, or just a failure that > was caused by 'that dodgy db driver again'. SolarMetric have had massive issues with this in setting up their test suites. There are a lot of buggy JDBC drivers out there when you start to push them hard. However, I don't think we need to aim to test every database out there. I'd be happy just to use an embedded database to start off. Greatly simplifies the config process also. I think a first goal might be Tomcat + HSQL. Easy to do the "just unzip" approach and meets the basic goal of verifying that we didn't break everyone's web app in changes today. The goal of saying "Spring works end to end on app server X" is a separate, but also important, goal, I think. Regards, Rod |
|
From: <jue...@we...> - 2003-10-22 22:19:07
|
VGhvbWFzLA0KIA0KSSd2ZSBzZWVuIHRob3NlIG1ldGFkYXRhIHRlc3RzIGZhaWwgdG9vLiBBcyB0 aGUgd2hvbGUgbWV0YWRhdGEgcGFja2FnZSB3aWxsIG5vdCBiZSBpbmNsdWRlZCBpbiB0aGUgMS4w IE0yIHJlbGVhc2UgYW55d2F5LCB0aGlzIHNob3VsZG4ndCByZWFsbHkgbWF0dGVyIGZvciB0aGUg dGltZSBiZWluZy4gSSd2ZSBleGNsdWRlZCB0aGVtIGZyb20gdGhlIHRlc3QgcnVuIGluIG15IGxv Y2FsIGJ1aWxkLnByb3BlcnRpZXMgZmlsZS4NCiANCkp1ZXJnZW4NCiANCg0KCS0tLS0tVXJzcHLD vG5nbGljaGUgTmFjaHJpY2h0LS0tLS0gDQoJVm9uOiB0cmlzYmVyZ0B0cmlkYi5jb20gW21haWx0 bzp0cmlzYmVyZ0B0cmlkYi5jb21dIA0KCUdlc2VuZGV0OiBNaSAyMi4xMC4yMDAzIDIyOjI2IA0K CUFuOiBzcHJpbmdmcmFtZXdvcmstZGV2ZWxvcGVyQGxpc3RzLnNvdXJjZWZvcmdlLm5ldCANCglD YzogDQoJQmV0cmVmZjogUmU6IFtTcHJpbmdmcmFtZXdvcmstZGV2ZWxvcGVyXSBQcmVwYXJpbmcg Zm9yIDEuMCBNMg0KCQ0KCQ0KDQoJSSdtIHN0aWxsIHNlZWluZyBhIGZldyBlcnJvcnMgcnVubmlu ZyB0aGUgdGVzdHMuICBJZiBzb21lb25lIGhhcyB0aW1lIHRvIGxvb2sgYXQNCgl0aGlzLCB0aGVu IHdlIHNob3VsZCBkbyB0aGlzIGJlZm9yZSBGcmlkYXkuICBJZiBub3QsIHRoZW4gd2Ugc2hvdWxk IGF0IGxlYXN0DQoJY29tbWVudCBvdXQgdGhlIGZhaWxpbmcgdGVzdHMgYW5kIHRhZyB0aGVtIHdp dGggYSBUT0RPIG5vdGUgKEkgY2FuIGRvIHRoaXMNCglUaHVyc2RheSBuaWdodCkuICBJIGRvbid0 IHRoaW5rIHdlIHNob3VsZCByZWxlYXNlIHdpdGhvdXQgaGF2aW5nIGFsbCB0ZXN0cyBwYXNzaW5n Lg0KCQ0KCUhlcmUgaXMgbW9yZSBkZXRhaWw6DQoJDQoJQXBhY2hlIEFudCB2ZXJzaW9uIDEuNS4y IGNvbXBpbGVkIG9uIEZlYnJ1YXJ5IDI4IDIwMDMNCglqYXZhIHZlcnNpb24gIjEuNC4yIg0KCUph dmEoVE0pIDIgUnVudGltZSBFbnZpcm9ubWVudCwgU3RhbmRhcmQgRWRpdGlvbiAoYnVpbGQgMS40 LjItYjI4KQ0KCUphdmEgSG90U3BvdChUTSkgQ2xpZW50IFZNIChidWlsZCAxLjQuMi1iMjgsIG1p eGVkIG1vZGUpDQoJDQoJQlVJTEQgRkFJTEVEDQoJZmlsZTpDOi9lY2xpcHNlL3dvcmtzcGFjZS9z cHJpbmcvYnVpbGQueG1sOjI4ODogVGVzdCBvcmcuc3ByaW5nZnJhbWV3b3JrLm1ldGFkYXQNCglh LmJjZWwuQXR0cmlidXRlV3JpdGVyVGVzdHMgZmFpbGVkDQoJDQoJVGVzdHN1aXRlOiBvcmcuc3By aW5nZnJhbWV3b3JrLm1ldGFkYXRhLmJjZWwuQXR0cmlidXRlV3JpdGVyVGVzdHMNCglUZXN0cyBy dW46IDUsIEZhaWx1cmVzOiAwLCBFcnJvcnM6IDEsIFRpbWUgZWxhcHNlZDogMS40MDYgc2VjDQoJ DQoJVGVzdGNhc2U6IHRlc3RBdHRyaWJ1dGVzIHRvb2sgMS4xNzEgc2VjDQoJVGVzdGNhc2U6IHRl c3RCYWRBYmJyZXZpYXRlZEF0dHJpYnV0ZSB0b29rIDAuMTEgc2VjDQoJVGVzdGNhc2U6IHRlc3RB YmJyZXZpYXRlZEF0dHJpYnV0ZSB0b29rIDAuMDQ3IHNlYw0KCSAgICAgICAgQ2F1c2VkIGFuIEVS Uk9SDQoJQ291bGQgbm90IGNyZWF0ZSBjbGFzcyB1c2luZyBjbGFzc25hbWVzIFtQZXJzb25BdHRy aWJ1dGUsIFBlcnNvbkF0dHJpYnV0ZUF0dHJpYnV0ZV0NCglvcmcuc3ByaW5nZnJhbWV3b3JrLm1l dGFkYXRhLkF0dHJpYnV0ZUV4Y2VwdGlvbjogQ291bGQgbm90IGNyZWF0ZSBjbGFzcyB1c2luZw0K CWNsYXNzbmFtZXMgW1BlcnNvbkF0dHJpYnV0ZSwgUGVyc29uQXR0cmlidXRlQXR0cmlidXRlXQ0K CSAgICAgICAgYXQNCglvcmcuc3ByaW5nZnJhbWV3b3JrLm1ldGFkYXRhLnN1cHBvcnQuQXR0cmli dXRlQ3JlYXRvci5yZXNvbHZlQ2xhc3NuYW1lKEF0dHJpYnV0ZUNyZWF0b3IuamF2YToxMjkpDQoJ ICAgICAgICBhdA0KCW9yZy5zcHJpbmdmcmFtZXdvcmsubWV0YWRhdGEuc3VwcG9ydC5BdHRyaWJ1 dGVDcmVhdG9yLmNyZWF0ZUF0dHJpYnV0ZShBdHRyaWJ1dGVDcmVhdG9yLmphdmE6ODQpDQoJICAg ICAgICBhdA0KCW9yZy5zcHJpbmdmcmFtZXdvcmsubWV0YWRhdGEuYmNlbC5CY2VsQXR0cmlidXRl cy5jcmVhdGVPYmplY3QoQmNlbEF0dHJpYnV0ZXMuamF2YToyMjMpDQoJICAgICAgICBhdA0KCW9y Zy5zcHJpbmdmcmFtZXdvcmsubWV0YWRhdGEuYmNlbC5CY2VsQXR0cmlidXRlcy5nZXRBdHRyaWJ1 dGVzKEJjZWxBdHRyaWJ1dGVzLmphdmE6OTgpDQoJICAgICAgICBhdA0KCW9yZy5zcHJpbmdmcmFt ZXdvcmsubWV0YWRhdGEuYmNlbC5CY2VsQXR0cmlidXRlcy5nZXRBdHRyaWJ1dGVzKEJjZWxBdHRy aWJ1dGVzLmphdmE6NzEpDQoJICAgICAgICBhdA0KCW9yZy5zcHJpbmdmcmFtZXdvcmsubWV0YWRh dGEuYmNlbC5BdHRyaWJ1dGVXcml0ZXJUZXN0cy50ZXN0QWJicmV2aWF0ZWRBdHRyaWJ1dGUoQXR0 cmlidXRlV3JpdGVyVGVzdHMuamF2YToxNjEpDQoJICAgICAgICBhdCBzdW4ucmVmbGVjdC5OYXRp dmVNZXRob2RBY2Nlc3NvckltcGwuaW52b2tlMChOYXRpdmUgTWV0aG9kKQ0KCSAgICAgICAgYXQg c3VuLnJlZmxlY3QuTmF0aXZlTWV0aG9kQWNjZXNzb3JJbXBsLmludm9rZShOYXRpdmVNZXRob2RB Y2Nlc3NvckltcGwuamF2YTozOSkNCgkgICAgICAgIGF0DQoJc3VuLnJlZmxlY3QuRGVsZWdhdGlu Z01ldGhvZEFjY2Vzc29ySW1wbC5pbnZva2UoRGVsZWdhdGluZ01ldGhvZEFjY2Vzc29ySW1wbC5q YXZhOjI1KQ0KCQ0KCVRlc3RjYXNlOiB0ZXN0QWJicmV2aWF0ZWRBdHRyaWJ1dGVUZXN0Y2FzZTog dGVzdE1ldGhvZHMgdG9vayAwLjAzMiBzZWMNCglUZXN0Y2FzZTogdGVzdEZpZWxkcyB0b29rIDAu MDMxIHNlYw0KCQ0KCQ0KCQ0KCUJVSUxEIEZBSUxFRA0KCWZpbGU6QzovZWNsaXBzZS93b3Jrc3Bh Y2Uvc3ByaW5nL2J1aWxkLnhtbDoyODg6IFRlc3Qgb3JnLnNwcmluZ2ZyYW1ld29yay5tZXRhZGF0 DQoJYS5xZG94LkNvbXBpbGVyVGVzdHMgZmFpbGVkDQoJDQoJVGVzdHN1aXRlOiBvcmcuc3ByaW5n ZnJhbWV3b3JrLm1ldGFkYXRhLnFkb3guQ29tcGlsZXJUZXN0cw0KCVRlc3RzIHJ1bjogMSwgRmFp bHVyZXM6IDAsIEVycm9yczogMSwgVGltZSBlbGFwc2VkOiAxLjI1IHNlYw0KCQ0KCVRlc3RjYXNl OiB0ZXN0U2luZ2xlRmlsZSB0b29rIDEuMjM1IHNlYw0KCSAgICAgICAgQ2F1c2VkIGFuIEVSUk9S DQoJbnVsbA0KCWphdmEubGFuZy5OdWxsUG9pbnRlckV4Y2VwdGlvbg0KCSAgICAgICAgYXQgamF2 YS51dGlsLlN0cmluZ1Rva2VuaXplci48aW5pdD4oU3RyaW5nVG9rZW5pemVyLmphdmE6MTQ2KQ0K CSAgICAgICAgYXQgamF2YS51dGlsLlN0cmluZ1Rva2VuaXplci48aW5pdD4oU3RyaW5nVG9rZW5p emVyLmphdmE6MTYyKQ0KCSAgICAgICAgYXQNCglvcmcuc3ByaW5nZnJhbWV3b3JrLm1ldGFkYXRh LnN1cHBvcnQuQXR0cmlidXRlQ3JlYXRvci5wYXRoQXJyYXlUb1VSTEFycmF5KEF0dHJpYnV0ZUNy ZWF0b3IuamF2YTozODcpDQoJICAgICAgICBhdA0KCW9yZy5zcHJpbmdmcmFtZXdvcmsubWV0YWRh dGEucWRveC5RRG94TWV0YWRhdGFDb21waWxlci5nZXRDbGFzcyhRRG94TWV0YWRhdGFDb21waWxl ci5qYXZhOjIwOSkNCgkgICAgICAgIGF0DQoJb3JnLnNwcmluZ2ZyYW1ld29yay5tZXRhZGF0YS5x ZG94LlFEb3hNZXRhZGF0YUNvbXBpbGVyLmNvbXBpbGUoUURveE1ldGFkYXRhQ29tcGlsZXIuamF2 YToxMDkpDQoJICAgICAgICBhdA0KCW9yZy5zcHJpbmdmcmFtZXdvcmsubWV0YWRhdGEucWRveC5D b21waWxlclRlc3RzLnRlc3RTaW5nbGVGaWxlKENvbXBpbGVyVGVzdHMuamF2YTo1OSkNCgkgICAg ICAgIGF0IHN1bi5yZWZsZWN0Lk5hdGl2ZU1ldGhvZEFjY2Vzc29ySW1wbC5pbnZva2UwKE5hdGl2 ZSBNZXRob2QpDQoJICAgICAgICBhdCBzdW4ucmVmbGVjdC5OYXRpdmVNZXRob2RBY2Nlc3Nvcklt cGwuaW52b2tlKE5hdGl2ZU1ldGhvZEFjY2Vzc29ySW1wbC5qYXZhOjM5KQ0KCSAgICAgICAgYXQN CglzdW4ucmVmbGVjdC5EZWxlZ2F0aW5nTWV0aG9kQWNjZXNzb3JJbXBsLmludm9rZShEZWxlZ2F0 aW5nTWV0aG9kQWNjZXNzb3JJbXBsLmphdmE6MjUpDQoJDQoJVGVzdGNhc2U6IHRlc3RTaW5nbGVG aWxlDQoJDQoJDQoJDQoJDQoJDQoJPiBFdmVyeWJvZHksDQoJPg0KCT4gUmVwZWF0aW5nIG15c2Vs ZiBmcm9tIHRoZSBtYWlsIG9uIFZlbG9jaXR5IHN1cHBvcnQ6DQoJPg0KCT4gPiBQbGVhc2UgZ2l2 ZSBldmVyeXRoaW5nIG9uZSBsYXN0IHRyeSBpZiBwb3NzaWJsZSEgSWYgdGhlcmUgYXJlIG5vIGlz c3Vlcw0KCT4gdGlsbCB0b21vcnJvdyBldmVuaW5nLCBJIHdpbGwgcmVsZWFzZSAxLjAgTTIgRnJp ZGF5IG1vcm5pbmcgYXQgdGhlIGxhdGVzdC4NCgk+DQoJPiBHZW5lcmFsbHksIHBsZWFzZSByZS1h cHBseSB0aGUgY3VycmVudCBjb2RlYmFzZSB0byB5b3VyIGFwcHMgdG8gY2F0Y2ggYW55DQoJPiBs YXN0IG1pbnV0ZSBpc3N1ZXMuIFRoZXJlJ3ZlIGJlZW4gcXVpdGUgc29tZSBzZXJpb3VzIHJlZmFj dG9yaW5ncyBpbiB0aGUgbGFzdA0KCT4gZmV3IHdlZWtzOyBzb21lIHRoaW5ncyBjb3VsZCBoYXZl IHNsaXBwZWQgdGhyb3VnaCB0aGUgdGVzdCBzdWl0ZS4NCgk+DQoJPiBCVFcsIGNoZWNraW5nIG91 ciB0aGlyZC1wYXJ0eSBkZXBlbmRlbmNpZXMgaW4gdGhlIGRpc3RyaWJ1dGlvbiwgSSd2ZSBvbWl0 dGVkDQoJPiB0aGUgTG9nNEogamFyIGZvciB0aGUgdGltZSBiZWluZywgYXMgaXQgd2FzIGNvbW1l bnRlZCBvdXQgaW4gdGhlIHNhbXBsZXMNCgk+IGFueXdheSBkdWUgdG8gSkJvc3MgaXNzdWVzLiBD b21tb25zIExvZ2dpbmcgbG9ncyB0byB0aGUgY29uc29sZSBieSBkZWZhdWx0DQoJPiBub3csIGF0 IElORk8gbGV2ZWwuDQoJPg0KCT4gQXMgUGV0Y2xpbmljIG9mZmVycyBhIG5ldyBIaWJlcm5hdGUg aW1wbGVtZW50YXRpb24sIHRoZSBTcHJpbmcgZGlzdHJpYnV0aW9uDQoJPiBjb250YWlucyBIaWJl cm5hdGUgamFyIGZpbGVzIG5vdy4gVGhlIHRvdGFsIHNpemUgaXMgc3RpbGwgYmVsb3cgMTAgTUIs IDkuNyB0bw0KCT4gYmUgZXhhY3QuDQoJPg0KCT4gSnVlcmdlbg0KCT4NCgk+DQoJPiBESSBKw7xy Z2VuIEjDtmxsZXINCgk+IFNlbmlvciBTeXN0ZW0gQXJjaGl0ZWN0DQoJPiBfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KCT4NCgk+IHdlcmszQVRTIC0gZGl2aXNpb24gc3lz dGVtZW50d2lja2x1bmcNCgk+IHdlcmszQVQgaW5mb3JtYXRpb25zLSB1bmQgbWVkaWVuc3lzdGVt ZQ0KCT4NCgk+IGV1cm9wYXBsYXR6IDQNCgk+IEEgLSA0MDIwIGxpbnoNCgk+DQoJPiB0LiAgKzQz ICgwKSA3MzIgNzEgNjUgMjkgNTAyDQoJPiBmLiAgKzQzICgwKSA3MzIgNzEgNjUgMjkgMw0KCT4g bWFpbHRvOmp1ZXJnZW4uaG9lbGxlckB3ZXJrM2F0LmNvbQ0KCT4gaHR0cDovL3d3dy53ZXJrM2F0 LmNvbQ0KCT4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCgk+IHdlcmsz QVRTIC0gV0lSIEVOVFdJQ0tFTE4gRVJGT0xHDQoJPg0KCT4NCgk+IC0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCgk+IFRoaXMgU0YubmV0IGVt YWlsIGlzIHNwb25zb3JlZCBieSBPU0ROIGRldmVsb3BlciByZWxhdGlvbnMNCgk+IEhlcmUncyB5 b3VyIGNoYW5jZSB0byBzaG93IG9mZiB5b3VyIGV4dGVuc2l2ZSBwcm9kdWN0IGtub3dsZWRnZQ0K CT4gV2Ugd2FudCB0byBrbm93IHdoYXQgeW91IGtub3cuIFRlbGwgdXMgYW5kIHlvdSBoYXZlIGEg Y2hhbmNlIHRvIHdpbiAkMTAwDQoJPiBodHRwOi8vd3d3Lnpvb21lcmFuZy5jb20vc3VydmV5Lnpn aT9IUlBUMVgzUllRTkM1VjRNTE5TVjNFNTQNCgk+IF9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQoJPiBTcHJpbmdmcmFtZXdvcmstZGV2ZWxvcGVyIG1haWxp bmcgbGlzdA0KCT4gU3ByaW5nZnJhbWV3b3JrLWRldmVsb3BlckBsaXN0cy5zb3VyY2Vmb3JnZS5u ZXQNCgk+IGh0dHBzOi8vbGlzdHMuc291cmNlZm9yZ2UubmV0L2xpc3RzL2xpc3RpbmZvL3Nwcmlu Z2ZyYW1ld29yay1kZXZlbG9wZXINCgk+DQoJDQoJDQoJDQoJDQoJDQoJLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KCVRoaXMgU0YubmV0IGVt YWlsIGlzIHNwb25zb3JlZCBieSBPU0ROIGRldmVsb3BlciByZWxhdGlvbnMNCglIZXJlJ3MgeW91 ciBjaGFuY2UgdG8gc2hvdyBvZmYgeW91ciBleHRlbnNpdmUgcHJvZHVjdCBrbm93bGVkZ2UNCglX ZSB3YW50IHRvIGtub3cgd2hhdCB5b3Uga25vdy4gVGVsbCB1cyBhbmQgeW91IGhhdmUgYSBjaGFu Y2UgdG8gd2luICQxMDANCglodHRwOi8vd3d3Lnpvb21lcmFuZy5jb20vc3VydmV5LnpnaT9IUlBU MVgzUllRTkM1VjRNTE5TVjNFNTQNCglfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0KCVNwcmluZ2ZyYW1ld29yay1kZXZlbG9wZXIgbWFpbGluZyBsaXN0DQoJ U3ByaW5nZnJhbWV3b3JrLWRldmVsb3BlckBsaXN0cy5zb3VyY2Vmb3JnZS5uZXQNCglodHRwczov L2xpc3RzLnNvdXJjZWZvcmdlLm5ldC9saXN0cy9saXN0aW5mby9zcHJpbmdmcmFtZXdvcmstZGV2 ZWxvcGVyDQoJDQoNCg== |
|
From: <jue...@we...> - 2003-10-22 22:07:15
|
RGFycmVuLA0KIA0KSSd2ZSBhbHJlYWR5IGNvbnNpZGVyZWQgdGhhdCBmb3IgYSB3aGlsZS4gSSdt IG5vdCBzdXJlIGFib3V0IHRocmVlIGRpc3RyaWJ1dGlvbnMsIGJ1dCBhdCBsZWFzdCB0d28gZGVm aW5pdGVseSBtYWtlIHNlbnNlLCB0aGF0IGlzLCBhIGJhc2ljICJmcmFtZXdvcmstb25seSIgb25l IGFuZCBhIGZ1bGwgInNhbXBsZXMtYW5kLWV2ZXJ5dGhpbmciIG9uZS4gQ3VycmVudGx5LCB3ZSBk b24ndCBzaGlwIHRoZSB0ZXN0IHN1aXRlIGF0IGFsbCwgYXMgd2Ugd291bGQgaGF2ZSB0byBpbmNs dWRlIGFsbCBkZXBlbmRlbmNpZXMgKHF1aXRlIGEgbG90IG9mIGphciBmaWxlcykgdG9vLiBTdWNo IGFuICJ0ZXN0cy1hbGwtZGVwZW5kZW5jaWVzIiBvbmUgY291bGQgYmUgYSB0aGlyZCBkaXN0cm8u DQogDQpGb3IgdGhlIHRpbWUgYmVpbmcsIG9uZSBzaW5nbGUgZGlzdHJpYnV0aW9uIGF0IGFib3V0 IDEwIE1CIGlzIGZpbmUsIEkgdGhpbmsuIFdoZW4gbW92aW5nIHRvd2FyZHMgMS4wIGZpbmFsIGFm dGVyIHRoZSBtaWxlc3RvbmVzLCB3ZSBzaG91bGQgcmVjb25zaWRlciBzZXBhcmF0ZSBkaXN0cmli dXRpb25zLiBBcyBmYXIgYXMgSSBzZWUgdGhvdWdoLCBtb3N0IG90aGVyIG9wZW4gc291cmNlIHBy b2plY3RzIHNoaXAgZWl0aGVyIG9uZSBzaW5nbGUgZGlzdHJpYnV0aW9uIHdpdGggc2FtcGxlcyBh bmQgc291cmNlIGJ1dCBubyB0ZXN0cyAobGlrZSBMb2c0SiksIG9yIHNlcGFyYXRlICJiaW5hcmll cy13aXRoLXNhbXBsZXMiIGFuZCAic291cmNlLW9ubHkiIGRpc3RyaWJ1dGlvbnMgKGxpa2UgbW9z dCBvdGhlciBKYWthcnRhIHByb2R1Y3RzKS4NCiANCkp1ZXJnZW4NCiANCiANCg0KCS0tLS0tVXJz cHLDvG5nbGljaGUgTmFjaHJpY2h0LS0tLS0gDQoJVm9uOiBEYXJyZW4gRGF2aXNvbiBbbWFpbHRv OmRhcnJlbkBkYXZpc29uLnVrLm5ldF0gDQoJR2VzZW5kZXQ6IE1pIDIyLjEwLjIwMDMgMjE6MTIg DQoJQW46IHNwcmluZ2ZyYW1ld29yay1kZXZlbG9wZXJAbGlzdHMuc291cmNlZm9yZ2UubmV0IA0K CUNjOiANCglCZXRyZWZmOiBSZTogW1NwcmluZ2ZyYW1ld29yay1kZXZlbG9wZXJdIFByZXBhcmlu ZyBmb3IgMS4wIE0yDQoJDQoJDQoNCglPbiBXZWRuZXNkYXkgMjIgT2N0b2JlciAyMDAzIDE4OjA2 LCBqw7xyZ2VuIGjDtmxsZXIgW3dlcmszQVRdIHdyb3RlOg0KCQ0KCT4gQXMgUGV0Y2xpbmljIG9m ZmVycyBhIG5ldyBIaWJlcm5hdGUgaW1wbGVtZW50YXRpb24sIHRoZSBTcHJpbmcgZGlzdHJpYnV0 aW9uDQoJPiBjb250YWlucyBIaWJlcm5hdGUgamFyIGZpbGVzIG5vdy4gVGhlIHRvdGFsIHNpemUg aXMgc3RpbGwgYmVsb3cgMTAgTUIsIDkuNw0KCT4gdG8gYmUgZXhhY3QuDQoJDQoJSXMgdGhlcmUg YW55IGFkdmFudGFnZSB0byBzcGxpdHRpbmcgdGhlIGZpbGUgcmVsZWFzZXMgaW50byBzZXBhcmF0 ZSBtb2R1bGVzPyAgDQoJTXkgZ3Vlc3Mgd291bGQgYmUgdGhhdCBhZnRlciAxLjAgZmluYWwgaXMg cmVsZWFzZWQsIG1vc3QgdXNlcnMgd291bGQgY2hvb3NlDQoJdG8gZ3JhYiB0aGUgY29tcGlsZWQg amFyIGZpbGVzIChwb3NzaWJseSB3aXRoIGEgc3JjLWphciB0byBhaWQgZGVidWdnaW5nKSBhbmQN Cgl1c2UgdGhlbSBhbG9uZ3NpZGUgb25saW5lIGRvY3MgYW5kIGphdmFkb2NzLiAgQSBzdWJzZXQg b2YgdGhvc2Ugd291bGQgdGhlbg0KCXdhbnQgdG8gZ2V0IHRoZSBzYW1wbGUgYXBwcywgYW5kIGZl d2VyIHN0aWxsIHdvdWxkIHdhbnQgYm90aCBtYWluIGFuZCB0ZXN0DQoJc291cmNlIHRyZWVzLiAg QW55dGhpbmcgdGhhdCBoZWxwcyBpbmNyZWFzZSB1cHRha2Ugc2hvdWxkIGJlIGdvb2QsIGFuZCBJ DQoJdGhpbmsgaXQgb25seSBpbnZvbHZlcyBhbiBhZGRpdGlvbmFsL21vZGlmaWVkIGFudCB0YXNr Lg0KCQ0KCVNvcnJ5IGlmIHRoaXMgaGFzIGJlZW4gZGlzY3Vzc2VkIGJlZm9yZSwgYnV0IEkgY291 bGRuJ3Qgc2VlIGl0IGZyb20gYSBxdWljaw0KCXNlYXJjaCBvZiB0aGUgbGlzdCBhcmNoaXZlcy4u Lg0KCQ0KCQ0KCS0tDQoJDQoJRGFycmVuIERhdmlzb24NCglQdWJsaWMgS2V5OiBodHRwOi8vd3d3 LmRhdmlzb24udWsubmV0L2tleS5qc3ANCgkNCgkNCgkNCgktLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoJVGhpcyBTRi5uZXQgZW1haWwgaXMg c3BvbnNvcmVkIGJ5IE9TRE4gZGV2ZWxvcGVyIHJlbGF0aW9ucw0KCUhlcmUncyB5b3VyIGNoYW5j ZSB0byBzaG93IG9mZiB5b3VyIGV4dGVuc2l2ZSBwcm9kdWN0IGtub3dsZWRnZQ0KCVdlIHdhbnQg dG8ga25vdyB3aGF0IHlvdSBrbm93LiBUZWxsIHVzIGFuZCB5b3UgaGF2ZSBhIGNoYW5jZSB0byB3 aW4gJDEwMA0KCWh0dHA6Ly93d3cuem9vbWVyYW5nLmNvbS9zdXJ2ZXkuemdpP0hSUFQxWDNSWVFO QzVWNE1MTlNWM0U1NA0KCV9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQoJU3ByaW5nZnJhbWV3b3JrLWRldmVsb3BlciBtYWlsaW5nIGxpc3QNCglTcHJpbmdm cmFtZXdvcmstZGV2ZWxvcGVyQGxpc3RzLnNvdXJjZWZvcmdlLm5ldA0KCWh0dHBzOi8vbGlzdHMu c291cmNlZm9yZ2UubmV0L2xpc3RzL2xpc3RpbmZvL3NwcmluZ2ZyYW1ld29yay1kZXZlbG9wZXIN CgkNCg0K |
|
From: Darren D. <da...@da...> - 2003-10-22 21:22:39
|
On Wednesday 22 October 2003 18:06, j=FCrgen h=F6ller [werk3AT] wrote: > As Petclinic offers a new Hibernate implementation, the Spring distributi= on > contains Hibernate jar files now. The total size is still below 10 MB, 9.7 > to be exact. Is there any advantage to splitting the file releases into separate modules= ? =20 My guess would be that after 1.0 final is released, most users would choose= =20 to grab the compiled jar files (possibly with a src-jar to aid debugging) a= nd=20 use them alongside online docs and javadocs. A subset of those would then= =20 want to get the sample apps, and fewer still would want both main and test= =20 source trees. Anything that helps increase uptake should be good, and I=20 think it only involves an additional/modified ant task. Sorry if this has been discussed before, but I couldn't see it from a quick= =20 search of the list archives... =2D-=20 Darren Davison Public Key: http://www.davison.uk.net/key.jsp |
|
From: <tri...@tr...> - 2003-10-22 20:43:12
|
I'm still seeing a few errors running the tests. If someone has time to look at this, then we should do this before Friday. If not, then we should at least comment out the failing tests and tag them with a TODO note (I can do this Thursday night). I don't think we should release without having all tests passing. Here is more detail: Apache Ant version 1.5.2 compiled on February 28 2003 java version "1.4.2" Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2-b28) Java HotSpot(TM) Client VM (build 1.4.2-b28, mixed mode) BUILD FAILED file:C:/eclipse/workspace/spring/build.xml:288: Test org.springframework.metadat a.bcel.AttributeWriterTests failed Testsuite: org.springframework.metadata.bcel.AttributeWriterTests Tests run: 5, Failures: 0, Errors: 1, Time elapsed: 1.406 sec Testcase: testAttributes took 1.171 sec Testcase: testBadAbbreviatedAttribute took 0.11 sec Testcase: testAbbreviatedAttribute took 0.047 sec Caused an ERROR Could not create class using classnames [PersonAttribute, PersonAttributeAttribute] org.springframework.metadata.AttributeException: Could not create class using classnames [PersonAttribute, PersonAttributeAttribute] at org.springframework.metadata.support.AttributeCreator.resolveClassname(AttributeCreator.java:129) at org.springframework.metadata.support.AttributeCreator.createAttribute(AttributeCreator.java:84) at org.springframework.metadata.bcel.BcelAttributes.createObject(BcelAttributes.java:223) at org.springframework.metadata.bcel.BcelAttributes.getAttributes(BcelAttributes.java:98) at org.springframework.metadata.bcel.BcelAttributes.getAttributes(BcelAttributes.java:71) at org.springframework.metadata.bcel.AttributeWriterTests.testAbbreviatedAttribute(AttributeWriterTests.java:161) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) Testcase: testAbbreviatedAttributeTestcase: testMethods took 0.032 sec Testcase: testFields took 0.031 sec BUILD FAILED file:C:/eclipse/workspace/spring/build.xml:288: Test org.springframework.metadat a.qdox.CompilerTests failed Testsuite: org.springframework.metadata.qdox.CompilerTests Tests run: 1, Failures: 0, Errors: 1, Time elapsed: 1.25 sec Testcase: testSingleFile took 1.235 sec Caused an ERROR null java.lang.NullPointerException at java.util.StringTokenizer.<init>(StringTokenizer.java:146) at java.util.StringTokenizer.<init>(StringTokenizer.java:162) at org.springframework.metadata.support.AttributeCreator.pathArrayToURLArray(AttributeCreator.java:387) at org.springframework.metadata.qdox.QDoxMetadataCompiler.getClass(QDoxMetadataCompiler.java:209) at org.springframework.metadata.qdox.QDoxMetadataCompiler.compile(QDoxMetadataCompiler.java:109) at org.springframework.metadata.qdox.CompilerTests.testSingleFile(CompilerTests.java:59) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) Testcase: testSingleFile > Everybody, > > Repeating myself from the mail on Velocity support: > > > Please give everything one last try if possible! If there are no issues > till tomorrow evening, I will release 1.0 M2 Friday morning at the latest. > > Generally, please re-apply the current codebase to your apps to catch any > last minute issues. There've been quite some serious refactorings in the last > few weeks; some things could have slipped through the test suite. > > BTW, checking our third-party dependencies in the distribution, I've omitted > the Log4J jar for the time being, as it was commented out in the samples > anyway due to JBoss issues. Commons Logging logs to the console by default > now, at INFO level. > > As Petclinic offers a new Hibernate implementation, the Spring distribution > contains Hibernate jar files now. The total size is still below 10 MB, 9.7 to > be exact. > > Juergen > > > DI Jürgen Höller > Senior System Architect > ______________________________________ > > werk3ATS - division systementwicklung > werk3AT informations- und mediensysteme > > europaplatz 4 > A - 4020 linz > > t. +43 (0) 732 71 65 29 502 > f. +43 (0) 732 71 65 29 3 > mailto:jue...@we... > http://www.werk3at.com > ______________________________________ > werk3ATS - WIR ENTWICKELN ERFOLG > > > ------------------------------------------------------- > This SF.net email is sponsored by OSDN developer relations > Here's your chance to show off your extensive product knowledge > We want to know what you know. Tell us and you have a chance to win $100 > http://www.zoomerang.com/survey.zgi?HRPT1X3RYQNC5V4MLNSV3E54 > _______________________________________________ > Springframework-developer mailing list > Spr...@li... > https://lists.sourceforge.net/lists/listinfo/springframework-developer > |
|
From: Darren D. <da...@da...> - 2003-10-22 19:25:42
|
On Wednesday 22 October 2003 17:10, j=FCrgen h=F6ller [werk3AT] wrote: > Please give everything one last try if possible! If there are no issues > till tomorrow evening, I will release 1.0 M2 Friday morning at the latest. worked fine here without any modification needed to a test Velocity app. =2D-=20 Darren Davison Public Key: http://www.davison.uk.net/key.jsp |
|
From: <jue...@we...> - 2003-10-22 18:44:35
|
Everybody, Repeating myself from the mail on Velocity support: > Please give everything one last try if possible! If there are no = issues till tomorrow evening, I will release 1.0 M2 Friday morning at = the latest. Generally, please re-apply the current codebase to your apps to catch = any last minute issues. There've been quite some serious refactorings in = the last few weeks; some things could have slipped through the test = suite. BTW, checking our third-party dependencies in the distribution, I've = omitted the Log4J jar for the time being, as it was commented out in the = samples anyway due to JBoss issues. Commons Logging logs to the console = by default now, at INFO level. As Petclinic offers a new Hibernate implementation, the Spring = distribution contains Hibernate jar files now. The total size is still = below 10 MB, 9.7 to be exact. Juergen DI J=FCrgen H=F6ller Senior System Architect ______________________________________ werk3ATS - division systementwicklung werk3AT informations- und mediensysteme europaplatz 4 A - 4020 linz t. +43 (0) 732 71 65 29 502 f. +43 (0) 732 71 65 29 3 mailto:jue...@we... http://www.werk3at.com ______________________________________ werk3ATS - WIR ENTWICKELN ERFOLG |
|
From: <jue...@we...> - 2003-10-22 18:29:54
|
Darren, all,
I've refactored our Velocity support today, into a generic =
VelocityEngineFactory and VelocityEngineFactoryBean plus a web-specific =
VelocityConfigurer for web views. The reason is that we are using =
Velocity for email content generation at werk3AT and needed a proper way =
to set up a VelocityEngine for this. VelocityEngineFactoryBean does =
exactly that, analogous to for example LocalSessionFactoryBean, offering =
the prepared VelocityEngine instance as bean reference.
From the web point of view, almost everything stays the same: There's =
still VelocityConfigurer etc. One property name has changed though: the =
former "webAppRootMarker" is called "appRootMarker" now. The web default =
is still "${webapp.root}" like before, so that shouldn't matter. BTW, =
this marker can be changed at the VelocityConfigurer level; it does not =
depend on the "webAppRootKey" in web.xml, it is just named accordingly =
for consistency reasons. The velocity-config article did not explain =
that correctly (already fixed).
Please give everything one last try if possible! If there are no issues =
till tomorrow evening, I will release 1.0 M2 Friday morning at the =
latest.
Juergen
DI J=FCrgen H=F6ller
Senior System Architect
______________________________________
werk3ATS - division systementwicklung
werk3AT informations- und mediensysteme
europaplatz 4
A - 4020 linz
t. +43 (0) 732 71 65 29 502
f. +43 (0) 732 71 65 29 3
mailto:jue...@we...
http://www.werk3at.com
______________________________________
werk3ATS - WIR ENTWICKELN ERFOLG
|
|
From: Kopylenko, D. <dko...@ac...> - 2003-10-22 07:54:07
|
Alef, just out of curiosity, can you explain what you're trying to do, may be with some examples. Regards, Dmitriy. -----Original Message----- From: Alef Arendsen (JTeam) [mailto:al...@jt...] Sent: Tuesday, October 21, 2003 11:41 AM To: 'Spring Developers' Subject: [Springframework-developer] Class file manipulation with BCEL safe? Hi all, I'm playing around with the source level metadata stuff and it looks really cool! I'm trying to implement some of our validation features using it and have successfully generated some classes using the MetaDataCompiler. However, I was wondering how BCEL affects the classes and if this is not going to bring us major problem when for instance serializing classes and stuff... Also, I once heard Hibernate uses asm and stuff, won't this bring any conflicts? I'm to use the functionality in our domain model... Might not be the right place to ask those kind of quesitons, but anyway... Thanx, Alef P.s. Joost, one of our people and the main backend guy here has moved to Spring completely by the way. He just said: hmmmm, it seems like those spring guys are actually doing a good job (it's really something if sceptic joost says something like that :-) == JTeam B.V. Donker Curtiusstraat 7-412 1051 JL Amsterdam T: +31 20 486 20 36 M: +31 6 24 11 1996 F: +31 84 837 00 00 E: al...@jt... W: <http://www.jteam.nl> http://www.jteam.nl |
|
From: Kopylenko, D. <dko...@ac...> - 2003-10-22 00:04:51
|
Folks, here is the JIRA issuie of the PicoContainer project about unanswered Spring vs. Pico comparising: http://jira.codehaus.org/secure/ViewIssue.jspa?key=PICO-18 Regards, Dmitriy. |
|
From: Colin S. <col...@ex...> - 2003-10-21 22:11:02
|
On my system, with current CVS head, these are currently breaking: AttributeWriterTests CompilerTests TransactionInterceptorTests Unfortunately I have zero time left today to try to look at any of these... :-( |
|
From: Alef A. \(JTeam\) <al...@jt...> - 2003-10-21 18:45:37
|
> * Tests should be repeatable and the results unambiguous. > This *may* involve > writing specific new test applications that focus on these > goals rather than > attempting to fit existing sample applications to the purpose > which may have > more of a user-educational benefit, or which are harder to > test in a regular > fashion. Sounds reasonable to me. The goal is to test Spring in production environments, not to test the sample applications. > * Test applications should be capable of automated > deployment and testing on > various J2EE server platforms. Well, that sounds handy, otherwise people must be involved every test :) > i. Given that no-one is likely to come forward with a large > array of high > powered hardware for our testing pleasure (but do feel free > to correct me), > the tests will need to be distributable. We will probably be > able to find a > semi-permanent home for testing Tomcat/JBOSS, but this is the > only way we > will be able to test against many other server platforms - in > particular the > heavyweight and expensive commercial ones. (SourceForge do > have a WebSphere > box in their compile farm, but I think it may be difficult to > run the sort of > tests we want to run there.) We're running a fully automated build here on three servers (well, you can hardly call them servers, they're PIII-800s with 512-1024 ram). One is the CVS server, one is the server building the projects, one of the dedicated test server. Right now we're testing on a jboss/jetty combo (tens of automated builds a day), but we've also been able to do weblogic/oracle combo concurrently. It _is_ going to be a problem to test WebSphere/9iAS on such machines however... If we need resources, I'll probably be able to free them... > ii. With distributable tests running ad-hoc on donated server > resources, it > may not be possible or desirable to operate tests that begin > with clean > platform installs. In some cases, the platform install may > simply be too > problematic to script anyway, even if time and resource > permitted. How > critical is this as a requirement? Whilst certainly feasible on > Tomcat/JBOSS, I'd suggest that trashing and re-deploying the > test apps on an > existing server install is the best we might get for WebLogic > / WebSphere et > al. I don't know how the other servers do it, as far as JBoss is concerned, the server-configuration directoyr is enough. We could just put that in the CVS ([jbosshome]/server/default for instance). We're having a standard jboss-installation on the testserver and we're updating the configuration directory each build (from the cvs). This works perfeclty. As I said, I don't know how weblogic/websphere/9iAS are handling this. > iii. Each application server will require it's own script(s), > perhaps even one > per test application per server. However, once a test application is > deployed, the actual test should be designed to be handled in a > server-agnostic manner unless deliberately testing specific platform > differences. Further investigation might show that something > like custom ANT > tasks would be of use somewhere here. Agree... > iv. Dependencies need careful consideration in how they may > affect test > results given a widespread test environment. The database > problem has > already been remarked upon, local dependencies such as db > drivers, different > versions of libraries in the lib/ext (or equivalent) > directory of the server > installation and even possibly different JDK versions are > elements that will > have to be dealt with which wouldn't necessarily be issues in > a testing lab. > It may be possible to report some of this information within > the test results > where sensible values can be retreived. Does anyone have > thoughts on this? JUnit does this automatically for the VM performing the test, doesn't it? As far as server configs are involved, are the tests going to move around across server that much to make it desirable to automate this? |
|
From: Colin S. <col...@ex...> - 2003-10-21 18:18:09
|
Aside from doing something homebrew, the other choice for documentation is probably Forrest, which I've never used: http://xml.apache.org/forrest/ Alef Arendsen (JTeam) wrote: >Well, I don't really like Maven for _building_ software. For putting out >documentation though, I think it's quite nice... > >Alef > > > > >>-----Oorspronkelijk bericht----- >>Van: spr...@li... >>[mailto:spr...@li...] >> Namens Colin Sampaleanu >>Verzonden: Thursday, October 16, 2003 7:16 PM >>Aan: Rod Johnson >>CC: 'Spring Developers' >>Onderwerp: Re: [Springframework-developer] Documentation >> >> >>I actually have a lot of experience with Maven, having >>tinkered with it >>a bunch over the last year (unfortunately, the multiproject support, >>where I think Maven becomes the most useful (along with the >>docs) to me, >>is still broken in some respects (property and repository >>overrides, for >>one), but that would not have an effect on Spring. >> >>If there is consensus on this, I am willing to put in some time to >>finish this up, as necessary. >> >> >>Rod Johnson wrote: >> >> >> >>>I believe Luke Tayler did a Maven build script which works. So we >>>certainly have a starting point. >>> >>>Rod >>> >>>----- Original Message ----- >>>From: "Colin Sampaleanu" <col...@ex...> >>>To: "'Spring Developers'" >>> >>> >><spr...@li...> >> >> >>>Sent: Thursday, October 16, 2003 5:17 PM >>>Subject: Re: [Springframework-developer] Documentation >>> >>> >>> >>> >>>>From my point of view, while of course there is a general need for >>> >>> >>>>more documentation and samples, what would also be of some >>>> >>>> >>use is some >> >> >>>>general infrastructure for producing consistent and relatively >>>>professional looking docs and a website. I am not a big fan >>>> >>>> >>of Maven >> >> >>>>generated websites with nothing in them, but on the other hand, if >>>>people are willing to write documentation, Maven (and other >>>>alternatives like Forrest) make it pretty easy to put out >>>>documentation without having to worry too much about the look and >>>>feel, linking it into the site, etc. >>>> >>>>W/regards to the possibility of using Maven, one option would be to >>>>use it just for doc generation, if doing the entire build >>>> >>>> >>with it is >> >> >>>>too onerous. This approach has been used by other projects... >>>> >>>>Regards, >>>>Colin >>>> >>>>Alef Arendsen (JTeam) wrote: >>>> >>>> >>>> >>>> >>>> >>>>>Hi all, >>>>> >>>>>Since I am busy closing 2002's financial year (doing all the >>>>>accounting and stuff; I never should have started a company :), I >>>>>desperately need some things I can do when I'm totally sick of all >>>>>those numbers and spreadsheets. No internal projects here, >>>>> >>>>> >>so I was >> >> >>>>>wondering if there already is a plan for how to improve our >>>>>documentation base or if there are if there other important things >>>>>that need to be addressed. >>>>> >>>>>Juergen, other people, any thoughts? >>>>> >>>>>Thanx, >>>>> >>>>>Alef >>>>> >>>>> |
|
From: <jue...@we...> - 2003-10-21 17:16:30
|
RGFycmVuLA0KDQpObywgdGhlcmUgaXNuJ3QgYW55dGhpbmcgbW9yZSB0aGFuIGVhcmx5IHZhbGlk YXRpb24uIDxyZWYgbG9jYWw9Ii4uLiIvPiBjYW4gYmUgY2hlY2tlZCBieSBYTUwgZWRpdG9ycyBh bmQgcGFyc2Vycywgd2hpbGUgPHJlZiBiZWFuPSIuLi4iLz4gd2lsbCBvbmx5IGJlIGNoZWNrZWQg YnkgdGhlIGJlYW4gZmFjdG9yeSBhdCBydW50aW1lLiBPZiBjb3Vyc2UsIGFsd2F5cyB1c2luZyA8 cmVmIGJlYW49Ii4uLiIvPiBpcyBmaW5lIGlmIHlvdSBkbyBub3Qgd2FudCB0aGlzIGtpbmQgb2Yg ZWFybHkgdmFsaWRhdGlvbi4NCg0KVGhlIG1haW4gaW50ZW50IGlzIHRvIGNsYXJpZnkgdGhlIHJv bGUgb2YgdGhlIG9sZCA8cmVmIGV4dGVybmFsPSIuLi4iLz46IFlvdSBjYW4gcmVmZXJlbmNlIGFu eSBiZWFuIHdpdGggdGhpcywgbm90IGp1c3QgZXh0ZXJuYWwgb25lcywgd2hpbGUgdGhlIG9sZCA8 cmVmIGJlYW49Ii4uLiIvPiBjYW4ganVzdCByZWZlcmVuY2UgWE1MIGlkcyBpbiB0aGUgc2FtZSBm aWxlLiBUaGUgbmV3IHNlbWFudGljcyBhbGxvdyA8cmVmIGJlYW49Ii4uLiIvPiB0byByZWZlcmVu Y2UgYW55IGJlYW4gKGFzIHRoZSBuYW1lIHN1Z2dlc3RzKSwgd2hpbGUgPHJlZiBsb2NhbD0iLi4u Ii8+IGNhbiBqdXN0IHJlZmVyZW5jZSBYTUwgaWRzIGluIHRoZSBzYW1lIGZpbGUuIFNvICJiZWFu IiBpcyB0aGUgZ2VuZXJpYyBvbmUsICJsb2NhbCIgdGhlIHNwZWNpYWwgb25lIHdpdGggWE1MIHZh bGlkYXRpb24gc2VtYW50aWNzLg0KDQo8cmVmIGV4dGVybmFsPSIuLi4iLz4gc3RpbGwgZXhpc3Rz LCB3aXRoIHRoZSBzYW1lIHNlbWFudGljcyBhcyA8cmVmIGJlYW49Ii4uLiIvPiwgYnV0IGl0IGlz IGRlcHJlY2F0ZWQgbm93LiBUaGUgZ29vZCB0aGluZyBpcyB0aGF0IGFsbCBleGlzdGluZyBhcHBs aWNhdGlvbiBjb250ZXh0IFhNTCBmaWxlcyB3aWxsIHN0aWxsIHdvcmsuIE9uZSBqdXN0IG5lZWRz IHRvIHVzZSA8cmVmIGxvY2FsPSIuLi4iLz4gdG8gbGV2ZXJhZ2UgWE1MIGlkIHZhbGlkYXRpb24g bm93OyB3aXRob3V0IGNoYW5nZXMsIDxyZWYgYmVhbj0iLi4uIi8+IHdpbGwgbm90IHZhbGlkYXRl IFhNTCBpZHMgYW55bW9yZS4NCg0KSnVlcmdlbg0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t LS0tDQpGcm9tOiBEYXJyZW4gRGF2aXNvbiBbbWFpbHRvOmRhcnJlbkBkYXZpc29uLnVrLm5ldF0N ClNlbnQ6IE1vbmRheSwgT2N0b2JlciAyMCwgMjAwMyA5OjE0IFBNDQpUbzogc3ByaW5nZnJhbWV3 b3JrLWRldmVsb3BlckBsaXN0cy5zb3VyY2Vmb3JnZS5uZXQNClN1YmplY3Q6IFJlOiBbU3ByaW5n ZnJhbWV3b3JrLWRldmVsb3Blcl0gWE1MIGJlYW4gcmVmZXJlbmNlcw0KDQoNCk9uIE1vbmRheSAy MCBPY3RvYmVyIDIwMDMgMTY6NTAsIGrDvHJnZW4gaMO2bGxlciBbd2VyazNBVF0gd3JvdGU6DQoN Cj4gSSdtIGluY2xpbmVkIHRvIGdvIHRoZSAiYmVhbiIgLyAibG9jYWwiIC8gImV4dGVybmFsIihk ZXByZWNhdGVkKSByb3V0ZQ0KPiBhZ2Fpbi4uLiBWb3RlcyBwbGVhc2UhIEdpdmVuIHRoaXMgZGVj aXNpb24sIEkgdm90ZSBmb3IgImxvY2FsIiBpbnN0ZWFkIG9mDQo+ICJpbnRlcm5hbCI7IENvbGlu IG9idmlvdXNseSBkb2VzIHRvby4NCg0KSXQncyBsaWtlbHkgSSdtIG1pc3Npbmcgc29tZXRoaW5n IG9idmlvdXMsIG1heWJlIGR1ZSB0byBub3QgdXNpbmcgU3ByaW5nIG9uIA0KcHJvamVjdHMgd2hl cmUgSSdkIHNlZSB0aGUgYWR2YW50YWdlIG9mIHRoaXMsIGJ1dCB3aGF0IGV4YWN0bHkgaXMgdGhl IA0KcmVhbC13b3JsZCBhZHZhbnRhZ2Ugb2YgaGF2aW5nIHRoZSBkaXN0aW5jdGlvbj8gIEkga25v dyBpdCBsZW5kcyB3ZWlnaHQgdG8gDQp0aGUgRFREIHZhbGlkYXRpb24gZm9yIGxvY2FsIGJlYW5z LCB3aGljaCBtZWFucyBteSBJREUgY2FuIHRlbGwgbWUgdGhhdCBJIA0KbWFkZSBhIHR5cG8gaW4g YSA8cmVmIGJlYW49ImZvbyIgLz4gdGFnIGJlZm9yZSB0aGUgbG9nZ2luZyBvdXRwdXQgZG9lcywg YnV0IA0KaXMgdGhlcmUgc29tZXRoaW5nIG1vcmU/ICBPciBpcyB0aGVyZSBtb3JlIG9mIGFuIGFk dmFudGFnZSB0aGFuIEkgY2FuIHNlZSANCmZyb20gdGhlIGFkZGl0aW9uYWwgdmFsaWRhdGlvbiAt IHBlcmZvcm1hbmNlLCBvciBjYWNoaW5nIG9yIHNvbWV0aGluZz8NCg0KSnVzdCBhIGJpdCBjdXJp b3VzIHNpbmNlIHBhcnQgb2YgdGhlIGRpc2N1c3Npb24gcmVsYXRlcyB0byB3aGF0IGlzIHRoZSAN CnNpbXBsZXN0IGNvbmNlcHQgYW5kIGl0IHNlZW1zIGFzIHRob3VnaCBpdCB3b3VsZCBiZSBzaW1w bGVzdCBhbGwgcm91bmQgaWYgDQo8cmVmIGJlYW49ImZvbyIgLz4gd2FzIHRoZSBvbmx5IGF0dHJp YnV0ZSwgd2hpY2ggd29ya2VkIGZvciBib3RoIGxvY2FsIGFuZCANCmV4dGVybmFsLg0KDQpJZiB0 aGVyZSBhcmUgZ29vZCByZWFzb25zIHRvIGtlZXAgdGhlIGRpc3RpbmN0aW9uLCB0aGVuIEknbSAr MSBmb3IgdGhlIA0KYmVhbi9sb2NhbCBvcHRpb24uDQoNClRJQSBmb3IgYW55IGluc2lnaHQuLg0K DQpSZWdhcmRzLA0KDQotLSANCg0KRGFycmVuIERhdmlzb24NClB1YmxpYyBLZXk6IGh0dHA6Ly93 d3cuZGF2aXNvbi51ay5uZXQva2V5LmpzcA0KDQoNCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KVGhpcyBTRi5uZXQgZW1haWwgaXMgc3Bv bnNvcmVkIGJ5IE9TRE4gZGV2ZWxvcGVyIHJlbGF0aW9ucw0KSGVyZSdzIHlvdXIgY2hhbmNlIHRv IHNob3cgb2ZmIHlvdXIgZXh0ZW5zaXZlIHByb2R1Y3Qga25vd2xlZGdlDQpXZSB3YW50IHRvIGtu b3cgd2hhdCB5b3Uga25vdy4gVGVsbCB1cyBhbmQgeW91IGhhdmUgYSBjaGFuY2UgdG8gd2luICQx MDANCmh0dHA6Ly93d3cuem9vbWVyYW5nLmNvbS9zdXJ2ZXkuemdpP0hSUFQxWDNSWVFOQzVWNE1M TlNWM0U1NA0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N ClNwcmluZ2ZyYW1ld29yay1kZXZlbG9wZXIgbWFpbGluZyBsaXN0DQpTcHJpbmdmcmFtZXdvcmst ZGV2ZWxvcGVyQGxpc3RzLnNvdXJjZWZvcmdlLm5ldA0KaHR0cHM6Ly9saXN0cy5zb3VyY2Vmb3Jn ZS5uZXQvbGlzdHMvbGlzdGluZm8vc3ByaW5nZnJhbWV3b3JrLWRldmVsb3Blcg0K |
|
From: <jue...@we...> - 2003-10-21 17:13:53
|
Ken, everybody, I actually consider it as most effective to demonstrate portability = between both Hibernate/JDBC and HSQL/MySQL. IMO, it would just = complicate the implementation and thus make it harder to understand the = codebase if there were different id generation strategies within the = JDBC implementation, and switching to Hibernate just possible for one of = the two supported databases. I don't want to discredit the DataFieldMaxValueIncrementer support, it = definitely has value for strong portability requirements. It doesn't = match any Hibernate's way of id generation abstraction though, and I'd = like to make the code as easy as possible to understand for people that = already have a working knowledge of Hibernate. I've already committed the changes: All 4 combinations (Hibernate/HSQL, = Hibernate/MySQL, JDBC/HSQL, JDBC/MySQL) work nicely; the default is = Hibernate/HSQL now. When accessing the same database, the JDBC and = Hibernate implementations can work on exactly the same contents. = Furthermore, any data access is transactional now, via = TransactionProxyFactoryBean. Please give the stuff a review, if you like -- it's gonna get shipped = without much further refinement, as 1.0 M2 is about to be released this = week. Regards, Juergen P.S.: As a minor side note, I've removed the MySQL Connector 3.0 in the = lib-new directory as it is GPL; we're not allowed to distribute it = without becoming GPL ourselves. MySQL Connector 2.0.14 should be good = enough for the time being. -----Original Message----- From: Ken Krebs [mailto:kk...@kk...] Sent: Monday, October 20, 2003 11:41 PM To: spr...@li... Subject: [[W3-SPAM]] - Re: [Springframework-developer] Petclinic Hibernate implementation - Email found in subject It might be most useful to implement one of the 2 databases as is using=20 the MaxValueIncrementer while implementing the other using Hibernate to = preserve both types of examples. Ken j=FCrgen h=F6ller [werk3AT] wrote: >Thomas, Trevor, > > =20 > >>Does Hibernate use a different ID strategy for different databases? I = think >> =20 >> >what is implemented in the Petclinic is a strategy that would work the = same >across different databses as long as there is a MaxValueIncrementer = implementation. > >I intend to configure Hibernate to use "identity" for all databases. = Setting the correct Hibernate dialect will lead to "auto_increment" on = MySQL and "identity" on HSQL then. In terms of the data model, this = simply means dropping the sequence tables and defining the id columns as = "auto_increment" respectively "identity" in the DDL scripts. > >Sure, MaxValueIncrementer adopts a very generic approach that will work = on any database, even if it doesn't support such a thing like identity = columns. The disadvantage is that the mechanism is normally not native = to the database and thus somewhat tied to the application. > > =20 > >>If we change the Petclinic JDBC implementation to use identity = columns, then we >> =20 >> >need to figure out how to run the insert and subsequent query to = retrieve the id >using the same connection whether we are in a transaction or not. > >This is very similar with MySQL and HSQL: You simply run the insert = without specifying a value for the id field, and query "select = last_insert_id()" respectively "call identity()" afterwards (I've looked = up the latter in Hibernate's MySQLDialect and HSQLDialect = implementations). Petclinic already uses MySQLJdbcClinic and = HSQLJdbcClinic subclasses; it should be easy to encapsulate the = id-fetching query there. > >Of course, the range of possible Petclinic JDBC implementations will = then be bound to identity-supporting databases. According to the = Hibernate docs, those are "DB2, MySQL, MS SQL Server, Sybase and = HypersonicSQL". Oracle is notably absent; I think we can live with = Petclinic not running on Oracle, if we can allow for a dynamic switch = between JDBC and Hibernate on both MySQL and HSQL that way! > > =20 > >>>auto-increment just allows to read in the actual id afterwards >>> =20 >>> >>This is not reliable for concurrent inserts (which is why I generally = use sequences. For the sample this should be sufficient though. >> =20 >> > >According to what I found out about MySQL, "last_insert_id" returns the = last used id on the same connection and is thus transactionally safe. = Don't know about HSQL, but I frankly don't mind for sample purposes. > >Juergen > > >------------------------------------------------------- >This SF.net email sponsored by: Enterprise Linux Forum Conference & = Expo >The Event For Linux Datacenter Solutions & Strategies in The Enterprise = >Linux in the Boardroom; in the Front Office; & in the Server Room=20 >http://www.enterpriselinuxforum.com >_______________________________________________ >Springframework-developer mailing list >Spr...@li... >https://lists.sourceforge.net/lists/listinfo/springframework-developer > > > =20 > ------------------------------------------------------- This SF.net email is sponsored by OSDN developer relations Here's your chance to show off your extensive product knowledge We want to know what you know. Tell us and you have a chance to win $100 http://www.zoomerang.com/survey.zgi?HRPT1X3RYQNC5V4MLNSV3E54 _______________________________________________ Springframework-developer mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springframework-developer |
|
From: Colin S. <col...@ex...> - 2003-10-21 17:06:20
|
Hibernate actually uses CGLib, which is a relatively high-level API. CGLib then does its lower level work with either BCEL or ASM (there is a cglib 1.0 version for each). In general, there is not much of a case for using BCEL instead of ASM (other than perhaps the fact that BCEL is Apache licensed, and ASM is LGPL). ASM is _way_ smaller (something like a tenth the size), a lot quicker, and produces a lot less objects while it is working. I am not 100%, but I think the new version (2.0) of CGLib may switch to using ASM exclusively. Javassist is another code generation library, which I use internally at work, and is also used in Tapestry and JBoss. It's quite nice, allowing you to do the same kinds of code manipulations which CGLib does, but also allowing you to insert new code with actual Java syntax... Regards, Colin Alef Arendsen (JTeam) wrote: > Hi all, > > I'm playing around with the source level metadata stuff and it looks > really cool! I'm trying to implement some of our validation features > using it and have successfully generated some classes using the > MetaDataCompiler. However, I was wondering how BCEL affects the > classes and if this is not going to bring us major problem when for > instance serializing classes and stuff… > > Also, I once heard Hibernate uses asm and stuff, won't this bring any > conflicts? I'm to use the functionality in our domain model… > > Might not be the right place to ask those kind of quesitons, but anyway… > > Thanx, > > Alef > > P.s. Joost, one of our people and the main backend guy here has moved > to Spring completely by the way. He just said: hmmmm, it seems like > those spring guys are actually doing a good job (it's really something > if sceptic joost says something like that :-) > > == > JTeam B.V. > Donker Curtiusstraat 7-412 > 1051 JL Amsterdam > T: +31 20 486 20 36 > M: +31 6 24 11 1996 > F: +31 84 837 00 00 > E: al...@jt... > W: _http://www.jteam.nl_ > |
|
From: Alef A. \(JTeam\) <al...@jt...> - 2003-10-21 16:20:21
|
Hi all, I'm playing around with the source level metadata stuff and it looks really cool! I'm trying to implement some of our validation features using it and have successfully generated some classes using the MetaDataCompiler. However, I was wondering how BCEL affects the classes and if this is not going to bring us major problem when for instance serializing classes and stuff. Also, I once heard Hibernate uses asm and stuff, won't this bring any conflicts? I'm to use the functionality in our domain model. Might not be the right place to ask those kind of quesitons, but anyway. Thanx, Alef P.s. Joost, one of our people and the main backend guy here has moved to Spring completely by the way. He just said: hmmmm, it seems like those spring guys are actually doing a good job (it's really something if sceptic joost says something like that :-) == JTeam B.V. Donker Curtiusstraat 7-412 1051 JL Amsterdam T: +31 20 486 20 36 M: +31 6 24 11 1996 F: +31 84 837 00 00 E: al...@jt... W: http://www.jteam.nl |
|
From: Alef A. \(JTeam\) <al...@jt...> - 2003-10-21 14:34:37
|
Well, I don't really like Maven for _building_ software. For putting out documentation though, I think it's quite nice... Alef > -----Oorspronkelijk bericht----- > Van: spr...@li... > [mailto:spr...@li...] > Namens Colin Sampaleanu > Verzonden: Thursday, October 16, 2003 7:16 PM > Aan: Rod Johnson > CC: 'Spring Developers' > Onderwerp: Re: [Springframework-developer] Documentation > > > I actually have a lot of experience with Maven, having > tinkered with it > a bunch over the last year (unfortunately, the multiproject support, > where I think Maven becomes the most useful (along with the > docs) to me, > is still broken in some respects (property and repository > overrides, for > one), but that would not have an effect on Spring. > > If there is consensus on this, I am willing to put in some time to > finish this up, as necessary. > > > Rod Johnson wrote: > > >I believe Luke Tayler did a Maven build script which works. So we > >certainly have a starting point. > > > >Rod > > > >----- Original Message ----- > >From: "Colin Sampaleanu" <col...@ex...> > >To: "'Spring Developers'" > <spr...@li...> > >Sent: Thursday, October 16, 2003 5:17 PM > >Subject: Re: [Springframework-developer] Documentation > > > > > > > > > >>From my point of view, while of course there is a general need for > >>more documentation and samples, what would also be of some > use is some > >>general infrastructure for producing consistent and relatively > >>professional looking docs and a website. I am not a big fan > of Maven > >>generated websites with nothing in them, but on the other hand, if > >>people are willing to write documentation, Maven (and other > >>alternatives like Forrest) make it pretty easy to put out > >>documentation without having to worry too much about the look and > >>feel, linking it into the site, etc. > >> > >>W/regards to the possibility of using Maven, one option would be to > >>use it just for doc generation, if doing the entire build > with it is > >>too onerous. This approach has been used by other projects... > >> > >>Regards, > >>Colin > >> > >>Alef Arendsen (JTeam) wrote: > >> > >> > >> > >>>Hi all, > >>> > >>>Since I am busy closing 2002's financial year (doing all the > >>>accounting and stuff; I never should have started a company :), I > >>>desperately need some things I can do when I'm totally sick of all > >>>those numbers and spreadsheets. No internal projects here, > so I was > >>>wondering if there already is a plan for how to improve our > >>>documentation base or if there are if there other important things > >>>that need to be addressed. > >>> > >>>Juergen, other people, any thoughts? > >>> > >>>Thanx, > >>> > >>>Alef > >>> > >>> > >>> > >> > >> > >>------------------------------------------------------- > >>This SF.net email is sponsored by: SF.net Giveback Program. > >>SourceForge.net hosts over 70,000 Open Source Projects. See > the people > >>who have HELPED US provide better services: Click here: > >>http://sourceforge.net/supporters.php > >>_______________________________________________ > >>Springframework-developer mailing list > >>Spr...@li... > >>https://lists.sourceforge.net/lists/listinfo/springframework -developer >> >> > > > > >------------------------------------------------------- >This SF.net email is sponsored by: SF.net Giveback Program. >SourceForge.net hosts over 70,000 Open Source Projects. See the people >who have HELPED US provide better services: Click here: >http://sourceforge.net/supporters.php >_______________________________________________ >Springframework-developer mailing list >Spr...@li... >https://lists.sourceforge.net/lists/listinfo/springframework-developer > > ------------------------------------------------------- This SF.net email is sponsored by: SF.net Giveback Program. SourceForge.net hosts over 70,000 Open Source Projects. See the people who have HELPED US provide better services: Click here: http://sourceforge.net/supporters.php _______________________________________________ Springframework-developer mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springframework-developer |
|
From: Darren D. <da...@da...> - 2003-10-21 04:00:06
|
On Saturday 11 October 2003 18:29, Rod Johnson wrote: > However it would also be good to have automated integration tests that help > to verify that code changes won't break user applications. This is > especially important before releases, but would be really useful possibly > as part of a nightly build process. (I don't see any point running unit > tests in a nightly build: developers shouldn't commit without doing that.) > I think it's important to move beyond ad hoc testing, not just for unit > testing. --remainder snipped-- as promised a few days ago, I spent a little while thinking about this and there are some challenges involved to meet even the primary goals. I'll outline some of my thoughts here, but I'd like to get some feedback from people on the list as to what is deemed really important and therefore worthwhile spending the time on before expanding much further. * The main goal as I understand it is to provide an application testing sandbox - ie one that focuses on the usage of Spring and not on the Spring classes or components themselves. In this way we hope to verify that changes to Spring which are known not to break compilation or unit testing of Spring itself, also can be shown not to break applications depending on it and/or maintain backward compatibility. * While such tests may be more important as new releases approach, there should be no impediment (time and machine resources notwithstanding) to performing such tests nightly against CVS snapshots. * Tests should be repeatable and the results unambiguous. This *may* involve writing specific new test applications that focus on these goals rather than attempting to fit existing sample applications to the purpose which may have more of a user-educational benefit, or which are harder to test in a regular fashion. * Results should be made public in a consistent, user-friendly format, possibly via html and with mail notifications to the dev-list. * Test applications should be capable of automated deployment and testing on various J2EE server platforms. These are the primary aims as I see them presently. If anyone has views of any kind on the primary aims, I'd be very keen to hear them via the list. Following on from these are some other thoughts that are influenced by implementation constraints, some of which are outright questions rather than suggestions for moving forward. i. Given that no-one is likely to come forward with a large array of high powered hardware for our testing pleasure (but do feel free to correct me), the tests will need to be distributable. We will probably be able to find a semi-permanent home for testing Tomcat/JBOSS, but this is the only way we will be able to test against many other server platforms - in particular the heavyweight and expensive commercial ones. (SourceForge do have a WebSphere box in their compile farm, but I think it may be difficult to run the sort of tests we want to run there.) ii. With distributable tests running ad-hoc on donated server resources, it may not be possible or desirable to operate tests that begin with clean platform installs. In some cases, the platform install may simply be too problematic to script anyway, even if time and resource permitted. How critical is this as a requirement? Whilst certainly feasible on Tomcat/JBOSS, I'd suggest that trashing and re-deploying the test apps on an existing server install is the best we might get for WebLogic / WebSphere et al. iii. Each application server will require it's own script(s), perhaps even one per test application per server. However, once a test application is deployed, the actual test should be designed to be handled in a server-agnostic manner unless deliberately testing specific platform differences. Further investigation might show that something like custom ANT tasks would be of use somewhere here. iv. Dependencies need careful consideration in how they may affect test results given a widespread test environment. The database problem has already been remarked upon, local dependencies such as db drivers, different versions of libraries in the lib/ext (or equivalent) directory of the server installation and even possibly different JDK versions are elements that will have to be dealt with which wouldn't necessarily be issues in a testing lab. It may be possible to report some of this information within the test results where sensible values can be retreived. Does anyone have thoughts on this? v. Unambiguous results may be a goal too far. It may be that results will have to be verified individually with someone deciding whether a 'failure' is really a failure that we need to be concerned with, or just a failure that was caused by 'that dodgy db driver again'. I'll keep my further thoughts to myself for now, I'd be keen to see what the feeling is about all of this. -- Darren Davison Public Key: http://www.davison.uk.net/key.jsp |
|
From: Colin S. <col...@ex...> - 2003-10-21 03:56:05
|
-------- Original Message -------- Subject: [easymock] EasyMock 1.0.1 available Date: Tue, 21 Oct 2003 01:45:01 +0200 From: Tammo Freese <fr...@ac...> Reply-To: eas...@ya... To: eas...@ya... Hello all, I have uploaded EasyMock 1.0.1. Changes: - convenience methods expectAndReturn() and expectAndThrow() (no JavaDoc yet, but tests and documentation) - numerous refactorings to open up EasyMock for extensions (beware, all the internal stuff may change without notice) Please let me know whether you like the new convenience methods or not. - Tammo PS I have done a short exploration to port the EasyMock class extension (which Joel Shellman provided on the file section) to EasyMock 1.0.1. If anyone is interested, please let me know. ------------------------ Yahoo! Groups Sponsor ---------------------~--> Rent DVDs from home. Over 14,500 titles. Free Shipping & No Late Fees. Try Netflix for FREE! http://us.click.yahoo.com/mk9osC/hP.FAA/3jkFAA/NhFolB/TM ---------------------------------------------------------------------~-> To unsubscribe from this group, send an email to: eas...@ya... Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ |
|
From: <tri...@tr...> - 2003-10-21 02:47:33
|
Juergen, > We don't need to address that at the DataSource level. Why not simply execute > the series of SQL operations within a transaction? With > DataSourceTransactionManager or HibernateTransactionManager, > DataSourceUtils.getConnection will always return the same Connection within a > thread-bound transaction. JtaTransactionManager depends on the JTA > implementation; any reasonable one with local transaction optimization will > return the same Connection within a transaction too. > I was not just thinking about the Petclinic. I can see a general need for running a series of SQL statements or procedcure calls thet depend on running within the same connection - maybe there is some database state kept at the connection level or for some other reason. If we want to use the available Spring JDBC objects like SqlUpdate and SqlQuery for this, then this type of data source might come in handy. Thomas |
|
From: <jue...@we...> - 2003-10-21 02:01:00
|
SSBzZWUsIHRoZXJlJ3MgYSBsaW1pdGF0aW9uIGluIHRlcm1zIG9mIGlzb2xhdGlvbiBsZXZlbC4g QnV0IGFzIHlvdSBzYWlkLCB0aGF0J3Mgbm90IGFuIGlzc3VlIHdpdGggdGhlIHNhbXBsZSBhcHAg YXQgYWxsLiBBY3R1YWxseSwgSSdtIGp1c3QgcGxheWluZyB3aXRoIHRoZSBpZGVudGl0eS1iYXNl ZCB2ZXJzaW9uLCBhbmQgaXQgd29ya3MgbGlrZSBhIGNoYXJtISBTd2l0Y2hpbmcgYmV0d2VlbiBK REJDIGFuZCBIaWJlcm5hdGUgb24gSFNRTCBpcyBhIGJyZWV6ZTsgaXQncyBhIHBlcmZlY3Qgc2hv d2Nhc2UgZm9yIHRoZSBEQU8gcGF0dGVybiEgSSdtIGdvbm5hIHBvbGlzaCB0aGF0IHN0dWZmIGEg Yml0IGFuZCBtYWtlIGl0IHJlYWR5IGZvciBwcm9wZXIgZGVwbG95bWVudDsgaXQgc2hvdWxkIGJl IHJlYWR5IGZvciBjaGVja2luIHRvbW9ycm93Lg0KIA0KSnVlcmdlbg0KIA0KDQoJLS0tLS1VcnNw csO8bmdsaWNoZSBOYWNocmljaHQtLS0tLSANCglWb246IFRyZXZvciBDb29rIFttYWlsdG86cHJp c2UwM0BzZW50ZXgubmV0XSANCglHZXNlbmRldDogTW8gMjAuMTAuMjAwMyAxOTozMCANCglBbjog c3ByaW5nZnJhbWV3b3JrLWRldmVsb3BlckBsaXN0cy5zb3VyY2Vmb3JnZS5uZXQgDQoJQ2M6IA0K CUJldHJlZmY6IFJFOiBbU3ByaW5nZnJhbWV3b3JrLWRldmVsb3Blcl0gUGV0Y2xpbmljIEhpYmVy bmF0ZSBpbXBsZW1lbnRhdGlvbg0KCQ0KCQ0KDQoJPG1lPg0KCWF1dG8taW5jcmVtZW50IGp1c3Qg YWxsb3dzIHRvIHJlYWQgaW4gdGhlIGFjdHVhbCBpZCBhZnRlcndhcmRzDQoJVGhpcyBpcyBub3Qg cmVsaWFibGUgZm9yIGNvbmN1cnJlbnQgaW5zZXJ0cyAod2hpY2ggaXMgd2h5IEkgZ2VuZXJhbGx5 IHVzZSBzZXF1ZW5jZXMpDQoJPC9tZT4NCgkNCgk8anVlcmdlbj4NCglUaGlzIGlzIG5vdCByZWxp YWJsZSBldmVuIHdpdGggcHJvcGVyIHRyYW5zYWN0aW9ucz8gU2hvdWxkbid0ICJsYXN0X2luc2Vy dF9pZCIgb3Igd2hhdGV2ZXIgaXQgaXMgY2FsbGVkIHJldHVybiB0aGUgbGFzdCBpbnNlcnRlZCBp ZCBpbiB0aGUgc2FtZSB0cmFuc2FjdGlvbiwgYWxsb3dpbmcgZm9yIGNvbmN1cnJlbnQgaW5zZXJ0 cyBpbiBkaWZmZXJlbnQgdHJhbnNhY3Rpb25zPw0KCTwvanVlcmdlbj4NCgkNCglXaXRoIHRyYW5z YWN0aW9ucyBpdCBzaG91bGQgZnVuY3Rpb24gcHJvcGVybHkuICBUaGUgcHJvYmxlbSBpcyB0aGF0 IHdpdGggdHJhbnNhY3Rpb25zIHlvdSBoYXZlIGRpZmZlcmVudCBsb2NraW5nIHN0cmF0ZWdpZXMg d2hpY2ggaGF2ZSBkaWZmZXJlbnQgcGVyZm9ybWFuY2UgdHJhZGUtb2ZmcyBkZXBlbmRpbmcgb24g dGhlIGxldmVsIHVzZWQuICBJJ3ZlIGZvdW5kIHRoYXQgdXNpbmcgaWRlbnRpdHkgdHlwZSBmaWVs ZHMgbWFrZXMgdHJhbnNhY3Rpb25zIGFuZCBzcGVjaWZpYyBsb2NraW5nIHN0cmF0ZWdpZXMgcmVx dWlyZWQuICBCeSB1c2luZyBhIHNlcXVlbmNlLCBJIGNhbiBjaG9vc2UgZGlmZmVyZW50IHRyYW5z YWN0aW9uL2xvY2tpbmcgc3RyYXRlZ2llcyBkZXBlbmRpbmcgb24gcmVxdWlyZW1lbnRzL3BlcmZv cm1hbmNlICh1c2luZyB0aGUgaWRlbnRpdHkgc2VlbXMgdG8gbGltaXQgbXkgb3B0aW9ucykuDQoJ DQoJQWxzbywgaXQncyBnZW5lcmFsbHkgYSBsb3QgaGFyZGVyIHRvIGNoYW5nZSB0aGUgZGIgKGVz cGVjaWFsbHkgdGhlIHByaW1hcnkga2V5KSBhZnRlciBpdCdzIGluIHByb2R1Y3Rpb24uICBJIGNh biBkbyBhbnl0aGluZyBJIHdhbnQgd2l0aCBzZXF1ZW5jZXMsIGJ1dCBJIGhhdmUgbW9yZSBsaW1p dGVkIG9wdGlvbnMgd2l0aCBpZGVudGl0eS4gIElmIHRoZXkgd29yayB0b2RheSBidXQgbm90IHRv bW9ycm93LCBpdCdzIG5vIGxvbmdlciBhIHNpbXBsZSBjb2RlIGNoYW5nZSAoYW5kIGdldHRpbmcg YnVybmVkIGJ5IHRoaXMgYSBmZXcgdGltZXMgbWFkZSBtZSBjaGFuZ2UgdG8gc2VxdWVuY2VzIGFz IGEgZGVmYXVsdCkuICBUaGF0J3MganVzdCBteSBleHBlcmllbmNlL3ByZWZlcmVuY2UuICBBcyBJ IG1lbnRpb25lZCB0aG91Z2gsIGluIHRoaXMgY2FzZSBpdCBzaG91bGQgd29yayBjb3JyZWN0bHks IGFuZCBzaW5jZSBpdCdzIGEgc2FtcGxlIGFwcCBjaGFuZ2luZyB0aGUgZGIgbGF0ZXIgaXMgcGVy ZmVjdGx5IGFjY2VwdGFibGUuICBTb3JyeSBJIHRvb2sgdXMgYSBsaXR0bGUgb2ZmLXRvcGljLg0K CQ0KCVRyZXZvcg0KCQ0KCQ0KCQ0KCS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0NCglUaGlzIFNGLm5ldCBlbWFpbCBpcyBzcG9uc29yZWQgYnkg T1NETiBkZXZlbG9wZXIgcmVsYXRpb25zDQoJSGVyZSdzIHlvdXIgY2hhbmNlIHRvIHNob3cgb2Zm IHlvdXIgZXh0ZW5zaXZlIHByb2R1Y3Qga25vd2xlZGdlDQoJV2Ugd2FudCB0byBrbm93IHdoYXQg eW91IGtub3cuIFRlbGwgdXMgYW5kIHlvdSBoYXZlIGEgY2hhbmNlIHRvIHdpbiAkMTAwDQoJaHR0 cDovL3d3dy56b29tZXJhbmcuY29tL3N1cnZleS56Z2k/SFJQVDFYM1JZUU5DNVY0TUxOU1YzRTU0 DQoJX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCglTcHJp bmdmcmFtZXdvcmstZGV2ZWxvcGVyIG1haWxpbmcgbGlzdA0KCVNwcmluZ2ZyYW1ld29yay1kZXZl bG9wZXJAbGlzdHMuc291cmNlZm9yZ2UubmV0DQoJaHR0cHM6Ly9saXN0cy5zb3VyY2Vmb3JnZS5u ZXQvbGlzdHMvbGlzdGluZm8vc3ByaW5nZnJhbWV3b3JrLWRldmVsb3Blcg0KCQ0KDQo= |
|
From: <jue...@we...> - 2003-10-20 22:28:16
|
VGhvbWFzLA0KIA0KV2UgZG9uJ3QgbmVlZCB0byBhZGRyZXNzIHRoYXQgYXQgdGhlIERhdGFTb3Vy Y2UgbGV2ZWwuIFdoeSBub3Qgc2ltcGx5IGV4ZWN1dGUgdGhlIHNlcmllcyBvZiBTUUwgb3BlcmF0 aW9ucyB3aXRoaW4gYSB0cmFuc2FjdGlvbj8gV2l0aCBEYXRhU291cmNlVHJhbnNhY3Rpb25NYW5h Z2VyIG9yIEhpYmVybmF0ZVRyYW5zYWN0aW9uTWFuYWdlciwgRGF0YVNvdXJjZVV0aWxzLmdldENv bm5lY3Rpb24gd2lsbCBhbHdheXMgcmV0dXJuIHRoZSBzYW1lIENvbm5lY3Rpb24gd2l0aGluIGEg dGhyZWFkLWJvdW5kIHRyYW5zYWN0aW9uLiBKdGFUcmFuc2FjdGlvbk1hbmFnZXIgZGVwZW5kcyBv biB0aGUgSlRBIGltcGxlbWVudGF0aW9uOyBhbnkgcmVhc29uYWJsZSBvbmUgd2l0aCBsb2NhbCB0 cmFuc2FjdGlvbiBvcHRpbWl6YXRpb24gd2lsbCByZXR1cm4gdGhlIHNhbWUgQ29ubmVjdGlvbiB3 aXRoaW4gYSB0cmFuc2FjdGlvbiB0b28uDQogDQpJJ2xsIG1ha2UgUGV0Y2xpbmljJ3MgQ2xpbmlj IGJ1c2luZXNzIG9iamVjdCB0cmFuc2FjdGlvbmFsIGFueXdheSwgbWFpbmx5IGFzIHNob3djYXNl IGZvciBTcHJpbmcncyB0cmFuc2FjdGlvbiBpbmZyYXN0cnVjdHVyZS4gU28gZXhlY3V0aW5nIGlu c2VydHMgd2l0aGluIGEgdHJhbnNhY3Rpb24gd2lsbCBiZSBuYXR1cmFsLg0KIA0KSnVlcmdlbg0K IA0KDQoJLS0tLS1VcnNwcsO8bmdsaWNoZSBOYWNocmljaHQtLS0tLSANCglWb246IHRyaXNiZXJn QHRyaWRiLmNvbSBbbWFpbHRvOnRyaXNiZXJnQHRyaWRiLmNvbV0gDQoJR2VzZW5kZXQ6IE1vIDIw LjEwLjIwMDMgMjA6MTcgDQoJQW46IHNwcmluZ2ZyYW1ld29yay1kZXZlbG9wZXJAbGlzdHMuc291 cmNlZm9yZ2UubmV0IA0KCUNjOiANCglCZXRyZWZmOiBSRTogW1NwcmluZ2ZyYW1ld29yay1kZXZl bG9wZXJdIFBldGNsaW5pYyBIaWJlcm5hdGUgaW1wbGVtZW50YXRpb24NCgkNCgkNCg0KCUp1ZXJn ZW4sDQoJDQoJPiBBY2NvcmRpbmcgdG8gd2hhdCBJIGZvdW5kIG91dCBhYm91dCBNeVNRTCwgImxh c3RfaW5zZXJ0X2lkIiByZXR1cm5zIHRoZSBsYXN0DQoJPiB1c2VkIGlkIG9uIHRoZSBzYW1lIGNv bm5lY3Rpb24gYW5kIGlzIHRodXMgdHJhbnNhY3Rpb25hbGx5IHNhZmUuIERvbid0IGtub3cNCgk+ IGFib3V0IEhTUUwsIGJ1dCBJIGZyYW5rbHkgZG9uJ3QgbWluZCBmb3Igc2FtcGxlIHB1cnBvc2Vz Lg0KCT4NCgkNCglIU1FMIGhhcyBJREVOVElUWSgpIHdoaWNoIHJldHVybnMgdGhlIGxhc3QgaWRl bnRpdHkgdmFsdWUgZm9yIHRoZSBjb25uZWN0aW9uIC0NCglzbyB0aGUgZnVuY3Rpb25hbGl0eSBp cyBiYXNpY2FsbHkgdGhlIHNhbWUuICBXZSBqdXN0IGhhdmUgdG8gbWFrZSBzdXJlIHRoYXQgd2UN Cgl1c2UgdGhlIHNhbWUgY29ubmVjdGlvbiAtIGFuIHNxbFVwZGF0ZSBmb2xsb3dlZCBieSBhbiBz cWxRdWVyeSBtaWdodCBub3QNCglndXJhbnRlZSB0aGlzLiAgSSBoYXZlIGJlZW4gdGhpbmtpbmcg YWJvdXQgY3JlYXRpbmcgYSBkYXRhc291cmNlIHRoYXQgbWFrZXMgdGhlDQoJc2FtZSBjb25lY3Rp b24gYXZhaWxhYmxlIGZvciBhIHNlcmllcyBvZiBkYXRhYmFzZSBpbnRlcmFjdGlvbnMgKHdpdGgN CglzdXByZXNzQ2xvc2UgdHVybmVkIG9uKSAtIGxpa2UgYSB0ZW1wb3JhcnkgU2luZ2xlQ29ubmVj dGlvbkRhdGFTb3VyY2UgY3JlYXRlZA0KCWZyb20gYSBwb29sZWQgRGF0YVNvdXJjZS4gDQoJDQoJ V2hhdCBkbyB5b3UgdGhpbmsgb2YgYSBNdWx0aXBsZVVzZUNvbm5lY3Rpb25EYXRhU291cmNlIHRo YXQgZ2V0cyBhIERhdGFTb3VyY2UNCglwYXNzZWQgaW4gdGhlIGNvbnN0cnVjdG9yLiAgVGhpcyBN dWx0aXBsZVVzZUNvbm5lY3Rpb25EYXRhU291cmNlIGNvdWxkIHRoZW4gYmUNCglwYXNzZWQgaW4g dG8gc2V2ZXJhbCBzcWxVcGRhdGUgb3Igc3FsUXVlcnkgb2JqZWN0cyBhbmQgZGVmbGVjdCBhbnkg YXR0ZW1wdHMgdG8NCgljbG9zZSBpdCBkdXJpbmcgdGhpcyBzZXF1ZW5jZSBvZiBkYXRhYmFzZSBp bnRlcmFjdGlvbi4gIEZpbmFsbHkgd2Ugd291bGQgY2FsbA0KCWRlc3Ryb3koKSBvbiB0aGUgTXVs dGlwbGVVc2VDb25uZWN0aW9uRGF0YVNvdXJjZSBjYXVzaW5nIHRoZSBjb25uZWN0aW9uIHRvIGJl DQoJcmV0dXJuZWQgdG8gdGhlIHBvb2wuDQoJDQoJVGhvbWFzDQoJDQoJDQoJDQoJLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KCVRoaXMgU0Yu bmV0IGVtYWlsIHNwb25zb3JlZCBieTogRW50ZXJwcmlzZSBMaW51eCBGb3J1bSBDb25mZXJlbmNl ICYgRXhwbw0KCVRoZSBFdmVudCBGb3IgTGludXggRGF0YWNlbnRlciBTb2x1dGlvbnMgJiBTdHJh dGVnaWVzIGluIFRoZSBFbnRlcnByaXNlDQoJTGludXggaW4gdGhlIEJvYXJkcm9vbTsgaW4gdGhl IEZyb250IE9mZmljZTsgJiBpbiB0aGUgU2VydmVyIFJvb20NCglodHRwOi8vd3d3LmVudGVycHJp c2VsaW51eGZvcnVtLmNvbQ0KCV9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQoJU3ByaW5nZnJhbWV3b3JrLWRldmVsb3BlciBtYWlsaW5nIGxpc3QNCglTcHJp bmdmcmFtZXdvcmstZGV2ZWxvcGVyQGxpc3RzLnNvdXJjZWZvcmdlLm5ldA0KCWh0dHBzOi8vbGlz dHMuc291cmNlZm9yZ2UubmV0L2xpc3RzL2xpc3RpbmZvL3NwcmluZ2ZyYW1ld29yay1kZXZlbG9w ZXINCgkNCg0K |
|
From: Ken K. <kk...@kk...> - 2003-10-20 22:03:18
|
It might be most useful to implement one of the 2 databases as is using=20 the MaxValueIncrementer while implementing the other using Hibernate to=20 preserve both types of examples. Ken j=FCrgen h=F6ller [werk3AT] wrote: >Thomas, Trevor, > > =20 > >>Does Hibernate use a different ID strategy for different databases? I = think >> =20 >> >what is implemented in the Petclinic is a strategy that would work the s= ame >across different databses as long as there is a MaxValueIncrementer impl= ementation. > >I intend to configure Hibernate to use "identity" for all databases. Set= ting the correct Hibernate dialect will lead to "auto_increment" on MySQL= and "identity" on HSQL then. In terms of the data model, this simply mea= ns dropping the sequence tables and defining the id columns as "auto_incr= ement" respectively "identity" in the DDL scripts. > >Sure, MaxValueIncrementer adopts a very generic approach that will work = on any database, even if it doesn't support such a thing like identity co= lumns. The disadvantage is that the mechanism is normally not native to t= he database and thus somewhat tied to the application. > > =20 > >>If we change the Petclinic JDBC implementation to use identity columns,= then we >> =20 >> >need to figure out how to run the insert and subsequent query to retriev= e the id >using the same connection whether we are in a transaction or not. > >This is very similar with MySQL and HSQL: You simply run the insert with= out specifying a value for the id field, and query "select last_insert_id= ()" respectively "call identity()" afterwards (I've looked up the latter = in Hibernate's MySQLDialect and HSQLDialect implementations). Petclinic a= lready uses MySQLJdbcClinic and HSQLJdbcClinic subclasses; it should be e= asy to encapsulate the id-fetching query there. > >Of course, the range of possible Petclinic JDBC implementations will the= n be bound to identity-supporting databases. According to the Hibernate d= ocs, those are "DB2, MySQL, MS SQL Server, Sybase and HypersonicSQL". Ora= cle is notably absent; I think we can live with Petclinic not running on = Oracle, if we can allow for a dynamic switch between JDBC and Hibernate o= n both MySQL and HSQL that way! > > =20 > >>>auto-increment just allows to read in the actual id afterwards >>> =20 >>> >>This is not reliable for concurrent inserts (which is why I generally u= se sequences. For the sample this should be sufficient though. >> =20 >> > >According to what I found out about MySQL, "last_insert_id" returns the = last used id on the same connection and is thus transactionally safe. Don= 't know about HSQL, but I frankly don't mind for sample purposes. > >Juergen > > >------------------------------------------------------- >This SF.net email sponsored by: Enterprise Linux Forum Conference & Expo >The Event For Linux Datacenter Solutions & Strategies in The Enterprise=20 >Linux in the Boardroom; in the Front Office; & in the Server Room=20 >http://www.enterpriselinuxforum.com >_______________________________________________ >Springframework-developer mailing list >Spr...@li... >https://lists.sourceforge.net/lists/listinfo/springframework-developer > > > =20 > |
|
From: Trevor C. <pr...@se...> - 2003-10-20 21:44:40
|
<me> auto-increment just allows to read in the actual id afterwards This is not reliable for concurrent inserts (which is why I generally = use sequences) </me> <juergen>=20 This is not reliable even with proper transactions? Shouldn't = "last_insert_id" or whatever it is called return the last inserted id in = the same transaction, allowing for concurrent inserts in different = transactions? </juergen> With transactions it should function properly. The problem is that with = transactions you have different locking strategies which have different = performance trade-offs depending on the level used. I've found that = using identity type fields makes transactions and specific locking = strategies required. By using a sequence, I can choose different = transaction/locking strategies depending on requirements/performance = (using the identity seems to limit my options). Also, it's generally a lot harder to change the db (especially the = primary key) after it's in production. I can do anything I want with = sequences, but I have more limited options with identity. If they work = today but not tomorrow, it's no longer a simple code change (and getting = burned by this a few times made me change to sequences as a default). = That's just my experience/preference. As I mentioned though, in this = case it should work correctly, and since it's a sample app changing the = db later is perfectly acceptable. Sorry I took us a little off-topic. Trevor |
1239 messages has been excluded from this view by a project administrator.
