springframework-developer — Spring Framework developers list

[Springframework-developer] Log4J references

[<jue...@we...>]

RnVubmlseSBlbm91Z2gsIEkndmUganVzdCBkaXNjb3ZlcmVkIGJ5IGFjY2lkZW50IHRoYXQgU3Rh
dGljTWVzc2FnZVNvdXJjZSBhbmQgVHJhbnNhY3Rpb25UZW1wbGF0ZSBzdGlsbCByZWZlcnJlZCB0
byBMb2c0SiBpbnN0ZWFkIG9mIENvbW1vbnMgTG9nZ2luZy4gSSB3b25kZXIgaG93IHRoYXQgc2xp
cHBlZCB0aHJvdWdoLiBHb29kIHRoYXQgSSB0cmllZCBKdWFuJ3MgbXVsdGlwbGUgc2V0QXBwbGlj
YXRpb25Db250ZXh0IGNhbGwgYnVnIHdpdGggc3RhbmRhbG9uZSAwLjkgOi0pDQogDQpKdWVyZ2Vu
DQo=

Re: [Springframework-developer] Current release plan - why delay package renaming?

[Luke T. <ne...@fr...>]

Rod Johnson wrote:

> ...
> 
> Unless for some such reason we end up with the support earlier, I
> think Spring 1.1 should have Web Services and JMS as the major new
> features. Because these are essentially "bolt-ons" that don't require
> extensive changes, we could probably get to 1.1 reasonably quickly
> from 1.0.

There seem to be quite a few potential new modules/components and there 
are already several distinct parts to Spring. Do you think it would be 
an idea to split the codebase into separate modules reflecting these 
different modules and making the dependencies between them more obvious? 
This is coming from a "Mavenised" perspective of project organisation 
where there is usually a one-one mapping between jars and sub-projects. 
You could have a core compent and separate sub-projects for beans, jdbc, 
persistence, MVC framework etc.

This would make it easier for people arriving new to the codebase to 
navigate through the source and work out exactly what is specific to a 
particular component. It would also make it easier to manage things as 
the project grows and more stuff potentially gets added, much of which 
is in fact independent and not well represented by a single source tree.

Just a thought since you're planning on rearranging soon for the new 
package names.

cheers,

Luke.


-- 
  Luke Taylor.                      Monkey Machine Ltd.
  PGP Key ID: 0x57E9523C            http://www.monkeymachine.ltd.uk

[Springframework-developer] Re: Posible bug?

[<jue...@we...>]

SnVhbiwNCiANCkkndmUganVzdCB2ZXJpZmllZCB0aGlzIHdpdGggMC45IC0gaXQgaW5kZWVkIGdl
dHMgY2FsbGVkIHR3aWNlIHRoZXJlLiBBcyBhIHdvcmthcm91bmQsIHlvdSBjb3VsZCBrZWVwIGEg
cmVmZXJlbmNlIHRvIHRoZSBhcHBsaWNhdGlvbiBjb250ZXh0IGluIHlvdXIgYmVhbiBhbmQgY2hl
Y2sgZm9yIGl0cyBleGlzdGVuY2U6DQogDQpwdWJsaWMgdm9pZCBzZXRBcHBsaWNhdGlvbkNvbnRl
eHQoQXBwbGljYXRpb25Db250ZXh0IGN0eCkgew0KICBpZiAodGhpcy5hcHBsaWNhdGlvbkNvbnRl
eHQgPT0gbnVsbCkgew0KICAgIHRoaXMuYXBwbGljYXRpb25Db250ZXh0ID0gY3R4Ow0KICAgIC8v
IGRvIHNvbWUgaW5pdGlhbGl6YXRpb24NCiAgfQ0KfQ0KIA0KV2l0aCBvdXIgY3VycmVudCBDVlMg
c3RhdGUgKDAuOS4xKSwgdGhpcyBkb2Vzbid0IG9jY3VyIGFueW1vcmUsIGFzIEkgcmVjZW50bHkg
cmV3b3JrZWQgdGhlIGluaXRpYWxpemF0aW9uIGNvbXBsZXRlbHkgZm9yIHRoZSBuZXcgUHJvcGVy
dHlSZXNvdXJjZUNvbmZpZ3VyZXIuIFRoZXJlJ3MgYW4gZXhwbGljaXQgY2hlY2sgZm9yIHN1Y2gg
cmVpbml0aWFsaXphdGlvbiBpbiBBYnN0cmFjdEFwcGxpY2F0aW9uQ29udGV4dCBzaW5jZSB0aGF0
Lg0KIA0KQlRXLCB3ZSB3aWxsIG9mZmljaWFsbHkgcmVsZWFzZSAwLjkuMSB0b21vcnJvdyAtIGl0
IHNob3VsZCByZW1lZHkgdGhpcyBiZWhhdmlvciBldmVuIHdpdGhvdXQgdGhlIGFib3ZlIG1lbnRp
b25lZCB3b3JrYXJvdW5kLg0KIA0KSnVlcmdlbiANCiANCiANCg0KCS0tLS0tVXJzcHLDvG5nbGlj
aGUgTmFjaHJpY2h0LS0tLS0gDQoJVm9uOiBKdWFuIENhcmxvcyBGdWVudGVzIFttYWlsdG86amNm
dWVudGVzQEFOVElDSVBBLmNsXSANCglHZXNlbmRldDogRG8gMDcuMDguMjAwMyAyMjowNiANCglB
bjogJ2pvaG5zb25yQHVzZXJzLnNvdXJjZWZvcmdlLm5ldCcgDQoJQ2M6ICdqaG9lbGxlckB1c2Vy
cy5zb3VyY2Vmb3JnZS5uZXQnIA0KCUJldHJlZmY6IFBvc2libGUgYnVnPw0KCQ0KCQ0KCVJvZCwg
aW4gdGhlIHppcCBpcyBzaW1wbGUgdGVzdCBjYXNlIGZvciB0aGUgcHJvYmxlbSBpJ20gZW5jb3Vu
dGVyaW5nLiBUaGUgcHJvYmxlbSBpcyB0aGF0IGV2ZXJ5IHRpbWUgSSBvYnRhaW4gYSBzaW5nbGV0
b24gYmVhbiBmcm9tIHRoZSBhcHBjb250ZXh0IHNldEFwcGxpY2F0aW9uQ29udGV4dCBpcyBpbm9r
ZWQuIFJlZ2FyZHMuIA0KDQoNCi0tLQ0KT3V0Z29pbmcgbWFpbCBpcyBjZXJ0aWZpZWQgVmlydXMg
RnJlZS4NCkNoZWNrZWQgYnkgQVZHIGFudGktdmlydXMgc3lzdGVtIChodHRwOi8vd3d3LmdyaXNv
ZnQuY29tKS4NClZlcnNpb246IDYuMC41MDUgLyBWaXJ1cyBEYXRhYmFzZTogMzAyIC0gUmVsZWFz
ZSBEYXRlOiAzMC8wNy8yMDAzDQoNCg0KPD4gDQoNCg==

Re: [Springframework-developer] Parser problems in com.interface21.web.context tests

[<jue...@we...>]

SSd2ZSBqdXN0IHJlY2hlY2tlZCB0aGUgaXNzdWU6IFRoZSB0ZXN0IHN1aXRlIG9ubHkgd29ya3Mg
d2l0aCBYZXJjZXMgY3VycmVudGx5LCBub3Qgd2l0aCBDcmltc29uLiBJIGRpZG4ndCBub3RpY2Ug
aXQsIGFzIEkgaGF2ZSBYZXJjZXMgaW4gbXkganJlL2xpYi9leHQgZGlyZWN0b3J5LiBDcmltc29u
IHNlZW1zIHRvIGNvbXBsYWluIHRoYXQgaXQgY2FuJ3QgcmVzb2x2ZSBzdWNoIGEgZW50aXR5IFVS
SSB3aXRob3V0IGhhdmluZyBhIGNsZWFyIGJhc2UgcGF0aCwgZGVzcGl0ZSBvdXIgY3VzdG9tIEVu
dGl0eVJlc29sdmVyIGltcGxlbWVudGF0aW9uIHRoYXQgd291bGQgcmVzb2x2ZSBpdCBsb2NhbGx5
ICh2aWEgdGhlIGFwcGxpY2F0aW9uIGNvbnRleHQgcmVzb3VyY2UgYmFzZSkgYW55d2F5LiBYZXJj
ZXMgc2VlbXMgdG8gZmlyc3QgcGFzcyB0aGUgVVJJIHRvIHRoZSBFbnRpdHlSZXNvbHZlciwgd2hp
Y2ggaXMgbW9yZSBjb3JyZWN0IElNTy4NCiANClRoaXMgb25seSBvY2N1cnMgd2hlbiB1c2luZyBl
bnRpdHkgcmVmZXJlbmNlcyB0byBpbmNsdWRlIGFwcGxpY2F0aW9uIGNvbnRleHQgc25pcHBldHMg
aW4gdGhlIG1haW4gY29udGV4dCBkZWZpbml0aW9uLCBsaWtlIHRoZSBhcHBsaWNhdGlvbkNvbnRl
eHQueG1sIHJlZmVyZW5jZWQgYnkgUmVzb3VyY2VCdW5kbGVNZXNzYWdlU291cmNlVGVzdFN1aXRl
IGRvZXM6DQogDQo8IURPQ1RZUEUgYmVhbnMgUFVCTElDICItLy9TUFJJTkcvL0RURCBCRUFOLy9F
TiIgImh0dHA6Ly93d3cuc3ByaW5nZnJhbWV3b3JrLm9yZy9kdGQvc3ByaW5nLWJlYW5zLmR0ZCIg
Ww0KPCFFTlRJVFkgY29udGV4dEluY2x1ZGUgU1lTVEVNICJjb20vaW50ZXJmYWNlMjEvd2ViL2Nv
bnRleHQvV0VCLUlORi9jb250ZXh0SW5jbHVkZS54bWwiPg0KXT4NCiANCkkndmUgYWRkZWQgY29u
dGV4dCBpbmNsdWRlIGNhcGFiaWxpdHkgdmlhIFhNTCBlbnRpdHkgcmVmZXJlbmNlcyBqdXN0IGxh
c3Qgd2Vlaywgc28gdGhpcyBpcyByYXRoZXIgcmVjZW50LiBUaGlzIGVycm9uZW91cyBiZWhhdmlv
ciBvbiBDcmltc29uIHNob3VsZG4ndCBiZSBhIHByb2JsZW0gdGhvdWdoLCBhcyBub3JtYWwgbm9u
LWluY2x1ZGUgYXBwbGljYXRpb24gY29udGV4dHMgYXJlbid0IGFmZmVjdGVkIGJ5IGl0LiBTbyBv
dXIgKnRlc3Qgc3VpdGUqIG5lZWRzIFhlcmNlcyBmb3IgdGhlIG1vbWVudDogT2YgY291cnNlIHdl
IGNvdWxkIHJlbW92ZSB0aGUgY29udGV4dCBpbmNsdWRlIHRlc3RzLCBidXQgSSdkIHJhdGhlciBr
ZWVwIHRoZSB0ZXN0cyBhbmQgZGVwZW5kIG9uIFhlcmNlcy4gTWF5YmUgSSdsbCBkaWcgaW50byBD
cmltc29uIHNvbWUgdGltZSwgdG8gZmluZCBvdXQgaWYgd2UgY2FuIGRvIGFueXRoaW5nIGFib3V0
IGl0cyBiZWhhdmlvci4NCiANCkp1ZXJnZW4NCiANCiANCg0KCS0tLS0tVXJzcHLDvG5nbGljaGUg
TmFjaHJpY2h0LS0tLS0gDQoJVm9uOiBMdWtlIFRheWxvciBbbWFpbHRvOm5lZ2F0b25AZnJlZXN1
cmYuY2hdIA0KCUdlc2VuZGV0OiBEbyAwNy4wOC4yMDAzIDE3OjI5IA0KCUFuOiBzcHJpbmdmcmFt
ZXdvcmstZGV2ZWxvcGVyQGxpc3RzLnNvdXJjZWZvcmdlLm5ldCANCglDYzogDQoJQmV0cmVmZjog
W1NwcmluZ2ZyYW1ld29yay1kZXZlbG9wZXJdIFBhcnNlciBwcm9ibGVtcyBpbiBjb20uaW50ZXJm
YWNlMjEud2ViLmNvbnRleHQgdGVzdHMNCgkNCgkNCg0KCUhpLA0KCQ0KCUkndmUganVzdCB1cGRh
dGVkIHRoZSBNYXZlbiBzdHVmZg0KCQ0KCWh0dHA6Ly9tb25rZXltYWNoaW5lLmF0aC5jeC9zcHJp
bmcvbWF2ZW4tcmVwb3J0cy5odG1sDQoJDQoJYW5kIGFtIHNlZWluZyBzb21lIGVycm9ycyBpbiB0
aGlzIHBhY2thZ2Ugd2hpY2ggYXJlbid0IHRoZXJlIHdpdGggdGhlDQoJbm9ybWFsIHRlc3QgcnVu
Lg0KCQ0KCWUuZy4gIEV4Y2VwdGlvbiBpbiBjb25zdHJ1Y3RvcjogdGVzdENvdW50DQoJKG9yZy54
bWwuc2F4LlNBWFBhcnNlRXhjZXB0aW9uOiBSZWxhdGl2ZSBVUkkNCgkiY29tL2ludGVyZmFjZTIx
L3dlYi9jb250ZXh0L1dFQi1JTkYvY29udGV4dEluY2x1ZGUueG1sIjsgY2FuIG5vdCBiZQ0KCXJl
c29sdmVkIHdpdGhvdXQgYSBiYXNlIFVSSS4NCgkNCglodHRwOi8vbW9ua2V5bWFjaGluZS5hdGgu
Y3gvc3ByaW5nL2p1bml0LXJlcG9ydC5odG1sI1Jlc291cmNlQnVuZGxlTWVzc2FnZVNvdXJjZVRl
c3RTdWl0ZQ0KCQ0KCVRoZSBleGNlcHRpb24gaXMgdGhyb3duIGZyb20gaGVyZToNCgkNCglodHRw
Oi8vbW9ua2V5bWFjaGluZS5hdGguY3gvc3ByaW5nL3hyZWYvY29tL2ludGVyZmFjZTIxL2JlYW5z
L2ZhY3RvcnkveG1sL1htbEJlYW5GYWN0b3J5Lmh0bWwjMjI4DQoJDQoJSSB0aGluayBhbnQgaXMg
dXNpbmcgeGVyY2VzLCB3aGVyZWFzIE1hdmVuIGlzIHVzaW5nIGNyaW1zb24gZnJvbSB0aGUgSkRL
DQoJKEknbSB1c2luZyAxLjQuMV8wMykuIElmIHNvIHRoZW4gaXQgbWlnaHQgYmUgYW4gaWRlYSB0
byB0aWR5IHVwIHRoZQ0KCXRlc3RzIHRvIGJlIGNvbXBhdGlibGUgd2l0aCBib3RoIHBhcnNlcnMu
IEkgc3VwcG9zZSB0aGVyZSBjb3VsZA0KCXBvdGVudGlhbGx5IGJlIGltcGxlbWVudGF0aW9uIHBy
b2JsZW1zIHRvby4NCgkNCglMdWtlLg0KCQ0KCQ0KCS0tDQoJICBMdWtlIFRheWxvci4gICAgICAg
ICAgICAgICAgICAgICAgTW9ua2V5IE1hY2hpbmUgTHRkLg0KCSAgUEdQIEtleSBJRDogMHg1N0U5
NTIzQyAgICAgICAgICAgIGh0dHA6Ly93d3cubW9ua2V5bWFjaGluZS5sdGQudWsNCgkNCgkNCgkN
CgkNCgkNCgktLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tDQoJVGhpcyBTRi5OZXQgZW1haWwgc3BvbnNvcmVkIGJ5OiBGcmVlIHByZS1idWlsdCBB
U1AuTkVUIHNpdGVzIGluY2x1ZGluZw0KCURhdGEgUmVwb3J0cywgRS1jb21tZXJjZSwgUG9ydGFs
cywgYW5kIEZvcnVtcyBhcmUgYXZhaWxhYmxlIG5vdy4NCglEb3dubG9hZCB0b2RheSBhbmQgZW50
ZXIgdG8gd2luIGFuIFhCT1ggb3IgVmlzdWFsIFN0dWRpbyAuTkVULg0KCWh0dHA6Ly9hc3BuZXQu
Y2xpY2stdXJsLmNvbS9nby9wc2EwMDEwMDAwM2F2ZS9kaXJlY3Q7YXQuYXNwbmV0XzA3MjMwM18w
MS8wMQ0KCV9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoJ
U3ByaW5nZnJhbWV3b3JrLWRldmVsb3BlciBtYWlsaW5nIGxpc3QNCglTcHJpbmdmcmFtZXdvcmst
ZGV2ZWxvcGVyQGxpc3RzLnNvdXJjZWZvcmdlLm5ldA0KCWh0dHBzOi8vbGlzdHMuc291cmNlZm9y
Z2UubmV0L2xpc3RzL2xpc3RpbmZvL3NwcmluZ2ZyYW1ld29yay1kZXZlbG9wZXINCgkNCg0K

RE: [Springframework-developer] Release plan

[<jue...@we...>]

RHVlIHRvIGxhY2sgb2YgdGltZSwgSSdsbCBkbyB0aGlzIHRvbW9ycm93Lg0KSSBzdGlsbCBmYXZv
ciAwLjkuMSAtIFJvZCwgaXMgeW91ciBvYmplY3Rpb24gc2VyaW91cyBvciBqdXN0IG1pbm9yPyA7
LSkNCg0KSnVlcmdlbg0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBqw7xy
Z2VuIGjDtmxsZXIgW3dlcmszQVRdIA0KU2VudDogVGh1cnNkYXksIEF1Z3VzdCAwNywgMjAwMyAx
MTo0OSBBTQ0KVG86IHJvZC5qb2huc29uQGludGVyZmFjZTIxLmNvbQ0KQ2M6IHNwcmluZ2ZyYW1l
d29yay1kZXZlbG9wZXJAbGlzdHMuc291cmNlZm9yZ2UubmV0DQpTdWJqZWN0OiBSRTogW1Nwcmlu
Z2ZyYW1ld29yay1kZXZlbG9wZXJdIFJlbGVhc2UgcGxhbg0KDQoNCkNvdW50ZXJleGFtcGxlOiBU
aGUgY3VycmVudCBUb21jYXQgdmVyc2lvbmluZyBwb2xpY3kgaXMgVG9tY2F0IDQuMS54LCB3aXRo
IGJvdGggYnVnZml4ZXMgYW5kIG5ldyBmZWF0dXJlcyBjb21pbmcgaW4gdGhhdCB0cmVlLiBUb21j
YXQgNC4wLjQgZXZlbiBpbnRyb2R1Y2VkIHRoZSBjb21wbGV0ZWx5IHJld3JpdHRlbiBDb3lvdGUg
YXMgSFRUUCBDb25uZWN0b3IgdG8gdGhlIDQuMC54IHNlcmllcy4gUmVzaW4gdXNlcyBhIHZlcnkg
c2ltaWxhciBwb2xpY3ksIGludHJvZHVjaW5nIHZhcmlvdXMgbmV3IGZlYXR1cmVzIHdpdGhpbiAy
LjEueC4gSGliZXJuYXRlIDIuMC4yIGp1c3QgaW50cm9kdWNlZCB0aGUgbmV3ICJjYXNjYWRlIG9y
cGhhbi1kZWxldGUiIGZlYXR1cmUuIA0KDQpBbGwgdGhpbmdzIGNvbnNpZGVyZWQsIDAuOS4xIGRv
ZXMgbm90IG5lY2Vzc2FyaWx5IHN1Z2dlc3QgYSBidWdmaXggcmVsZWFzZSwgYnV0IHJhdGhlciBh
IHJlbGVhc2Ugd2l0aCBidWdmaXhlcyBhbmQgbWlub3IgbmV3IGZlYXR1cmVzIDstKQ0KDQpKdWVy
Z2VuDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IHJvZC5qb2huc29uQGlu
dGVyZmFjZTIxLmNvbSBbbWFpbHRvOnJvZC5qb2huc29uQGludGVyZmFjZTIxLmNvbV0NClNlbnQ6
IFRodXJzZGF5LCBBdWd1c3QgMDcsIDIwMDMgMTA6NDggQU0NClRvOiBqw7xyZ2VuIGjDtmxsZXIg
W3dlcmszQVRdDQpDYzogUm9kIEpvaG5zb247IHNwcmluZ2ZyYW1ld29yay1kZXZlbG9wZXJAbGlz
dHMuc291cmNlZm9yZ2UubmV0DQpTdWJqZWN0OiBSRTogW1NwcmluZ2ZyYW1ld29yay1kZXZlbG9w
ZXJdIFJlbGVhc2UgcGxhbg0KDQoNCj5JJ20gbm90IGVudGlyZWx5IGhhcHB5IHdpdGggIjAuOTEi
LiBJZiB3ZSB3aWxsIG5hbWUgb3VyIDEuMCANCmZvbGxvdy11cCByZWxlYXNlIDEuMC4xLCAxLjAu
MiwgMS4xLCAxLjEuMSwgZXRjLCAiMC45MSIgaXMgDQpyYXRoZXIgaW4gY29uc2lzdGVudC4gQW5k
IEknbSBub3Qgc3VyZSBpZiBpdCByZWFsbHkgY2FycmllcyANCnRoZSBtZXNzYWdlICJpcyBzbGln
aHRseSBpbmNvbXBhdGlibGUiIC0gaXNuJ3QgIjAuOTEiIHNpbXBseSANCmEgZGlmZmVyZW50ICpu
b3RhdGlvbiogZm9yICIwLjkuMSI/IA0KDQpJdCdzIGEgdHJpdmlhbCBwb2ludCwgYnV0IEkgdGhp
bmsgb2YgMC45LjEgYXMgYSAic2xpZ2h0IHBhdGNoIA0KdG8gMC45IiwgcHJvYmFibHkgYSBidWcg
Zml4Lg0KDQowLjkxIGltcGxpZXMgdGhhdCBpdCdzIGEgbmV3IHJlbGVhc2UgcHJvZ3Jlc3NpdmVs
eSBjbG9zZXIgdG8gDQoxLjAsIGxpa2UgSlNQIDAuOTIuIE9mIGNvdXJzZSAwLjggdG8gMC45IHdv
dWxkIGhhdmUgbWFkZSB0aGlzIA0KcHJvZ3Jlc3Npb24gY2xlYXJlciwgYnV0IEkgdGhpbmsgd2Ug
d2VyZSByaWdodCB0byBzdGFydCB3aXRoIA0KMC45Lg0KDQpSZWdhcmRzLA0KUm9kDQpOSHpuNGkR
eGpqeg56XEpOctO9Smp6cXp+emp6DQo=

RE: [Springframework-developer] Velocity configuration patch (MVC framework)

[<jue...@we...>]

Hi Darren,

Thanks for the patch. I've just incorporated the idea into =
VelocityConfigurer itself. Generally, VelocityConfigurer offers more =
options now:

- by default, reads "WEB-INF/velocity.properties"
- different config file via "configLocation"
- "velocityProperties" to override certain properties in the bean =
definition
- or "velocityProperties" to specify all necessary properties in the =
bean definition
- a "webAppRootMarker" that gets replaced with the web app root =
directory in Velocity property values
- an "overrideLogging" flag to redirect Velocity log output to Commons =
logging (true by default)

This can look as follows:

  <bean id=3D"velocityConfigurer" =
class=3D"com.interface21.web.servlet.view.velocity.VelocityConfigurer">
    <!--
    <property =
name=3D"configLocation"><value>WEB-INF/my-velocity.properties</value></pr=
operty>
    -->
    <property name=3D"velocityProperties">
      <props>
        <prop key=3D"resource.loader">file</prop>
        <prop =
key=3D"file.resource.loader.class">org.apache.velocity.runtime.resource.l=
oader.FileResourceLoader</prop>
        <prop key=3D"file.resource.loader.path">${webapp.root}</prop>
      </props>
    </property>
  </bean>

The "webAppRootMarker" mechanism works for both local properties and =
Velocity config files. The default marker is "${webapp.root}", same as =
the default marker for the respective system property that gets used in =
Log4J config files to refer to the web app resource base (see =
WebAppRootListener and Log4jConfigListener). All occurences of this =
marker in Velocity property values get replaced with the web app root =
directory. Obviously, this just makes sense in path definitions.

I consider this more flexible than patching the path properties by =
resource loader name. For example, you might define not one resource =
loader but a chain of them. Your code wouldn't have worked then.

I hope you like the new mechanism - of course I'm open for feedback!

Regards,
Juergen


-----Original Message-----
From: dar...@hs... [mailto:dar...@hs...]
Sent: Wednesday, August 06, 2003 2:07 PM
To: spr...@li...
Subject: [Springframework-developer] Velocity configuration patch (MVC
framework)


I know you guys are busy with imminent package renames and releases, so
apologies in advance if this is the wrong time to be sending patches!

Attached is a class that extends
com.interface21.web.servlet.view.velocity.VelocityConfigurer in order to
permit velocity templates to be portably loaded from within the WAR =
without
having them in the source tree (and thereby the classpath).  The =
overridden
initApplicationContext() method prefixes the template path root with the
real path to the WAR root.  The javadoc for the class should make it =
clear.

In order for this to work, the superclass (VelocityConfigurer) needs to
have the location field promoted from private to protected.  The only
alternative would be to override the setLocation() method in
WarVelocityConfigurer too which is the wrong way to do it I think.  The
very trivial patch file for this change is also attached.

The code relies on the web container using exploded WAR files.  Tomcat =
and
WebSphere both do by default, but I'm not sure that WebLogic does.

Both changes are based on the 0.9 release (I've no access to CVS at =
present
to see if updates are available to this part of Spring) and have been
tested successfully in the following locations:

WebSphere 4.0.4 on Windows
WebSphere 5.0 on Windows
Tomcat 4.1.18 on Windows
Tomcat 4.1.24 on Linux

Regards,

Darren Davison
CIBM Intranet Team
int> 799 19431
ext> +44 (0)20 7991 9431

(See attached file: WarVelocityConfigurer.java)(See attached file:
VelocityConfigurer.patch)


_____________________________________________________

This transmission has been issued by a member of the HSBC Group=20
"HSBC" for the information of the addressee only and should not be=20
reproduced and / or distributed to any other person. Each page attached=20
hereto must be read in conjunction with any disclaimer which forms part=20
of it. Unless otherwise stated, this transmission is neither an offer =
nor the=20
solicitation of an offer to sell or purchase any investment. Its =
contents are=20
based on information obtained from sources believed to be reliable but
HSBC makes no representation and accepts no responsibility or liability =
as=20
to its completeness or accuracy.

[Springframework-developer] Parser problems in com.interface21.web.context tests

[Luke T. <ne...@fr...>]

Hi,

I've just updated the Maven stuff

http://monkeymachine.ath.cx/spring/maven-reports.html

and am seeing some errors in this package which aren't there with the 
normal test run.

e.g.  Exception in constructor: testCount 
(org.xml.sax.SAXParseException: Relative URI 
"com/interface21/web/context/WEB-INF/contextInclude.xml"; can not be 
resolved without a base URI.

http://monkeymachine.ath.cx/spring/junit-report.html#ResourceBundleMessageSourceTestSuite

The exception is thrown from here:

http://monkeymachine.ath.cx/spring/xref/com/interface21/beans/factory/xml/XmlBeanFactory.html#228

I think ant is using xerces, whereas Maven is using crimson from the JDK 
(I'm using 1.4.1_03). If so then it might be an idea to tidy up the 
tests to be compatible with both parsers. I suppose there could 
potentially be implementation problems too.

Luke.


-- 
  Luke Taylor.                      Monkey Machine Ltd.
  PGP Key ID: 0x57E9523C            http://www.monkeymachine.ltd.uk

RE : [Springframework-developer] petclinic, hsqldb, & jboss

[Jean-Pierre <jp...@jp...>]

Thanks Rajeev,

Jean-Pierre


-----Message d'origine-----
De=A0: spr...@li...
[mailto:spr...@li...] De la
part de Rajeev Kaul
Envoy=E9=A0: vendredi 1 ao=FBt 2003 19:45
=C0=A0: spr...@li...
Objet=A0: Re: [Springframework-developer] petclinic, hsqldb, & jboss

Jean-Pierre,
=A0
I found out that "MessageCache" error turned out to be a JBOSS
configuration issue.=A0 The JBOSS 3.2.1 ships out with recursivesearch
attribute (in jboss-service.xml) set to false as shown below:
=A0
<attribute name=3D"RecursiveSearch">False</attribute>
=A0
This should be changed to true as show below:
=A0
<attribute name=3D"RecursiveSearch">True</attribute>
=A0
Now the petclinic sample works fine under JBOSS.=A0=20
=A0
It may be obvious that when running under a managed environment like
JBOSS, the application-context.xml should be modified to comment the
datasource for non-J2ee environment, and uncomment the datasource for
J2EE environment.=A0 But I think it should be clearly=A0mentioned as one =
of
the steps required to make the sample app to work under JBOSS.
=A0
Rajeev Kaul

[Springframework-developer] BindUtils

[JP P. <jp....@ti...>]

Hi,

I would just to inform that I have a few days ago made a minor change in
web.BindUtils.

The bind and bindAndValidate methods didn't have the useful feature of
dealing with specific custom PropertyEditors. This feature was only in
BaseCommandController and its subClasses.

I added the feature with two goals:
- Strictly backward compatibility for the two exising methods including
the throws statement.
- Cohesiveness with the Controller version of the initBinder method.

In summary, simply a new signature is added for the two functions with a
new parameter 'initializer'. This parameter is an instance of the new
interface 'BindInitializer' providing an 'initBinder' callback method.
The new signatures throw ServletException like the Controller version.

Juergen, if you see anything with which you are unhappy, you can change
before the tomorrow's release.

Regards,
Jean-Pierre

RE : [Springframework-developer] Release plan

[Jean-Pierre <jp...@jp...>]

Hi,

Outer the "dot" debate in which I have no special mention, the release
plan seems well build.

- A 0.9xxx very soon for letting people using new features, especially
with Hibernate with no delay and letting us well prepare the 1.0M1.
- A 1.0M1 release with the directories changes. This one will have to be
released as soon as possible as we said for having the fewer people
involved in name changes. On the other hand, it has to be strongly
tested and is incompatible with a precipitated release. 

Juergen wrote:
<quote>
BTW, Christian Bauer has invited me to provide a Spring/Hibernate
tutorial for the HibernateExamples download, right alongside his
Tomcat/Hibernate tutorial. I consider this a great opportunity for
co-promotion! Hopefully I'll get it done till early October.
</quote>
Very good news!!!
It will potentially grow up Spring users and we have a cohesive view of
development with Hibernate team. I will myself be very interested. I
found clearly the documentation/demos for advanced Database use with
Hibernate and transactions tiny.

Regards,
Jean-Pierre

RE: [Springframework-developer] Release plan

[<jue...@we...>]

Q291bnRlcmV4YW1wbGU6IFRoZSBjdXJyZW50IFRvbWNhdCB2ZXJzaW9uaW5nIHBvbGljeSBpcyBU
b21jYXQgNC4xLngsIHdpdGggYm90aCBidWdmaXhlcyBhbmQgbmV3IGZlYXR1cmVzIGNvbWluZyBp
biB0aGF0IHRyZWUuIFRvbWNhdCA0LjAuNCBldmVuIGludHJvZHVjZWQgdGhlIGNvbXBsZXRlbHkg
cmV3cml0dGVuIENveW90ZSBhcyBIVFRQIENvbm5lY3RvciB0byB0aGUgNC4wLnggc2VyaWVzLiBS
ZXNpbiB1c2VzIGEgdmVyeSBzaW1pbGFyIHBvbGljeSwgaW50cm9kdWNpbmcgdmFyaW91cyBuZXcg
ZmVhdHVyZXMgd2l0aGluIDIuMS54LiBIaWJlcm5hdGUgMi4wLjIganVzdCBpbnRyb2R1Y2VkIHRo
ZSBuZXcgImNhc2NhZGUgb3JwaGFuLWRlbGV0ZSIgZmVhdHVyZS4gDQoNCkFsbCB0aGluZ3MgY29u
c2lkZXJlZCwgMC45LjEgZG9lcyBub3QgbmVjZXNzYXJpbHkgc3VnZ2VzdCBhIGJ1Z2ZpeCByZWxl
YXNlLCBidXQgcmF0aGVyIGEgcmVsZWFzZSB3aXRoIGJ1Z2ZpeGVzIGFuZCBtaW5vciBuZXcgZmVh
dHVyZXMgOy0pDQoNCkp1ZXJnZW4NCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJv
bTogcm9kLmpvaG5zb25AaW50ZXJmYWNlMjEuY29tIFttYWlsdG86cm9kLmpvaG5zb25AaW50ZXJm
YWNlMjEuY29tXQ0KU2VudDogVGh1cnNkYXksIEF1Z3VzdCAwNywgMjAwMyAxMDo0OCBBTQ0KVG86
IGrDvHJnZW4gaMO2bGxlciBbd2VyazNBVF0NCkNjOiBSb2QgSm9obnNvbjsgc3ByaW5nZnJhbWV3
b3JrLWRldmVsb3BlckBsaXN0cy5zb3VyY2Vmb3JnZS5uZXQNClN1YmplY3Q6IFJFOiBbU3ByaW5n
ZnJhbWV3b3JrLWRldmVsb3Blcl0gUmVsZWFzZSBwbGFuDQoNCg0KPkknbSBub3QgZW50aXJlbHkg
aGFwcHkgd2l0aCAiMC45MSIuIElmIHdlIHdpbGwgbmFtZSBvdXIgMS4wIA0KZm9sbG93LXVwIHJl
bGVhc2UgMS4wLjEsIDEuMC4yLCAxLjEsIDEuMS4xLCBldGMsICIwLjkxIiBpcyANCnJhdGhlciBp
biBjb25zaXN0ZW50LiBBbmQgSSdtIG5vdCBzdXJlIGlmIGl0IHJlYWxseSBjYXJyaWVzIA0KdGhl
IG1lc3NhZ2UgImlzIHNsaWdodGx5IGluY29tcGF0aWJsZSIgLSBpc24ndCAiMC45MSIgc2ltcGx5
IA0KYSBkaWZmZXJlbnQgKm5vdGF0aW9uKiBmb3IgIjAuOS4xIj8gDQoNCkl0J3MgYSB0cml2aWFs
IHBvaW50LCBidXQgSSB0aGluayBvZiAwLjkuMSBhcyBhICJzbGlnaHQgcGF0Y2ggDQp0byAwLjki
LCBwcm9iYWJseSBhIGJ1ZyBmaXguDQoNCjAuOTEgaW1wbGllcyB0aGF0IGl0J3MgYSBuZXcgcmVs
ZWFzZSBwcm9ncmVzc2l2ZWx5IGNsb3NlciB0byANCjEuMCwgbGlrZSBKU1AgMC45Mi4gT2YgY291
cnNlIDAuOCB0byAwLjkgd291bGQgaGF2ZSBtYWRlIHRoaXMgDQpwcm9ncmVzc2lvbiBjbGVhcmVy
LCBidXQgSSB0aGluayB3ZSB3ZXJlIHJpZ2h0IHRvIHN0YXJ0IHdpdGggDQowLjkuDQoNClJlZ2Fy
ZHMsDQpSb2QNCg==

RE: [Springframework-developer] Release plan

[<rod...@in...>]

>I'm not entirely happy with "0.91". If we will name our 1.0 
follow-up release 1.0.1, 1.0.2, 1.1, 1.1.1, etc, "0.91" is 
rather in consistent. And I'm not sure if it really carries 
the message "is slightly incompatible" - isn't "0.91" simply 
a different *notation* for "0.9.1"? 

It's a trivial point, but I think of 0.9.1 as a "slight patch 
to 0.9", probably a bug fix.

0.91 implies that it's a new release progressively closer to 
1.0, like JSP 0.92. Of course 0.8 to 0.9 would have made this 
progression clearer, but I think we were right to start with 
0.9.

Regards,
Rod

RE: [Springframework-developer] Release plan

[<jue...@we...>]

SSdtIG5vdCBlbnRpcmVseSBoYXBweSB3aXRoICIwLjkxIi4gSWYgd2Ugd2lsbCBuYW1lIG91ciAx
LjAgZm9sbG93LXVwIHJlbGVhc2UgMS4wLjEsIDEuMC4yLCAxLjEsIDEuMS4xLCBldGMsICIwLjkx
IiBpcyByYXRoZXIgaW4gY29uc2lzdGVudC4gQW5kIEknbSBub3Qgc3VyZSBpZiBpdCByZWFsbHkg
Y2FycmllcyB0aGUgbWVzc2FnZSAiaXMgc2xpZ2h0bHkgaW5jb21wYXRpYmxlIiAtIGlzbid0ICIw
LjkxIiBzaW1wbHkgYSBkaWZmZXJlbnQgKm5vdGF0aW9uKiBmb3IgIjAuOS4xIj8NCg0KQUZBSVIs
IHRoZSBvbmx5IG5vdGV3b3J0aHkgaW5jb21wYXRpYmlsaXRpZXMgYXJlIGluIHRoZSBBT1Agc3Vw
cG9ydCwgZm9yIGN1c3RvbSBpbnRlcmNlcHRvciBpbXBsZW1lbnRhdGlvbnMuIEJ1dCBsZXQncyBu
b3QgZm9yZ2V0IHRoYXQgMC45IGRpZG4ndCBldmVuIGluY2x1ZGUgYW4gYW9wYWxsaWFuY2UuamFy
IC0gdGhlcmUgd29uJ3QgYmUgbXVjaCBjdXN0b20gY29kZSBicm9rZW4sIGlmIGFueSBhdCBhbGwu
DQoNCkkgYWdyZWUgdGhhdCBpdCBpcyBpbXBvcnRhbnQgdG8gc3RheSAxMDAlIGNvbXBhdGlibGUg
Zm9yIGZvbGxvdy11cHMgdG8gKmZpbmFsKiByZWxlYXNlcy4gV2UgYXJlIGF0ICJwcmUtcmVsZWFz
ZSIgMC54IHRob3VnaDogTm90ZWQgc2xpZ2h0IGluY29tcGF0aWJpbGl0aWVzIGZyb20gb25lIHJl
bGVhc2UgdG8gdGhlIG5leHQgYXJlbid0IGFuIGlzc3VlIGhlcmUsIElNTy4NCg0KUmVnYXJkaW5n
IG9yZy5zcHJpbmdmcmFtZXdvcmsgZm9yIHRoZSBUU1MgYXJ0aWNsZTogRnVsbHkgYWdyZWVkLiBC
VFcsIENocmlzdGlhbiBCYXVlciBoYXMgaW52aXRlZCBtZSB0byBwcm92aWRlIGEgU3ByaW5nL0hp
YmVybmF0ZSB0dXRvcmlhbCBmb3IgdGhlIEhpYmVybmF0ZUV4YW1wbGVzIGRvd25sb2FkLCByaWdo
dCBhbG9uZ3NpZGUgaGlzIFRvbWNhdC9IaWJlcm5hdGUgdHV0b3JpYWwuIEkgY29uc2lkZXIgdGhp
cyBhIGdyZWF0IG9wcG9ydHVuaXR5IGZvciBjby1wcm9tb3Rpb24hIEhvcGVmdWxseSBJJ2xsIGdl
dCBpdCBkb25lIHRpbGwgZWFybHkgT2N0b2Jlci4gSW4gYW55IGNhc2UsIHRoaXMgbmVlZHMgdG8g
ZGVwZW5kIG9uIDEuMCBNMSB0b28sIHRvIGF2b2lkIGdldHRpbmcgb3V0ZGF0ZWQgd2l0aGluIGEg
c2hvcnQgdGltZS4NCg0KSnVlcmdlbg0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpG
cm9tOiBSb2QgSm9obnNvbiBbbWFpbHRvOnJvZC5qb2huc29uQGludGVyZmFjZTIxLmNvbV0NClNl
bnQ6IFRodXJzZGF5LCBBdWd1c3QgMDcsIDIwMDMgODo0MyBBTQ0KVG86IGrDvHJnZW4gaMO2bGxl
ciBbd2VyazNBVF07DQpzcHJpbmdmcmFtZXdvcmstZGV2ZWxvcGVyQGxpc3RzLnNvdXJjZWZvcmdl
Lm5ldA0KU3ViamVjdDogUmU6IFtTcHJpbmdmcmFtZXdvcmstZGV2ZWxvcGVyXSBSZWxlYXNlIHBs
YW4NCg0KDQpTb3VuZHMgbGlrZSBhIGdvb2QgcGxhbiwgYXMgaXQgbWlnaHQgYmUgcmlza3kgdG8g
cnVzaCB0aGUgbW9kdWxlIHN3aXRjaC4NCg0KUGxlYXNlIHRhZyBhcyAwLjkxLiBJIHRoaW5rIGl0
IHNob3VsZCBiZSAwLjkxIG5vdCAwLjkuMS4gSXQncyBub3QgYQ0KbWFpbnRlbmFuY2UgcmVsZWFz
ZSBvZiAwLjkgYXMgdGhlcmUgYXJlIGluY29tcGF0aWJpbGllcy4NCg0KSSB0aGluayB3ZSBzaG91
bGQgdHJ5IHRvIGdldCB0byAxLjAgTTEgaW4gMi0zIHdlZWtzLiBJIHRoaW5rIHRoZSBvbGQNCmFy
Z3VtZW50cyBzdGlsbCBhcHBseSBhYm91dCBicmVha2luZyBwZW9wbGUncyBjb2RlIGVhcmxpZXIg
cmF0aGVyIHRoYW4NCmxhdGVyLg0KDQpSZWdhcmRzLg0KUm9kDQoNCi0tLS0tIE9yaWdpbmFsIE1l
c3NhZ2UgLS0tLS0NCkZyb206ICJqw7xyZ2VuIGjDtmxsZXIgW3dlcmszQVRdIiA8anVlcmdlbi5o
b2VsbGVyQHdlcmszYXQuY29tPg0KVG86IDxzcHJpbmdmcmFtZXdvcmstZGV2ZWxvcGVyQGxpc3Rz
LnNvdXJjZWZvcmdlLm5ldD4NClNlbnQ6IFdlZG5lc2RheSwgQXVndXN0IDA2LCAyMDAzIDk6Mzcg
UE0NClN1YmplY3Q6IFtTcHJpbmdmcmFtZXdvcmstZGV2ZWxvcGVyXSBSZWxlYXNlIHBsYW4NCg0K
DQo+IEd1eXMsDQo+DQo+IFdlJ3JlIGdldHRpbmcgcmVhbGx5IGRlbGF5ZWQgaGVyZS4gSSBvcmln
aW5hbGx5IGludGVuZGVkIHRvIHN0aWNrIHRvIGEgNg0Kd2VlayByZWxlYXNlIHNjaGVkdWxlIC0g
cmVsZWFzZSBlYXJseSwgcmVsZWFzZSBvZnRlbiwgaXNuJ3QgaXQ/IFRoYXQncyB3aHkgSQ0KY2hh
bmdlZCBteSBtaW5kIGEgYml0IHJlZ2FyZGluZyB1cGNvbWluZyByZWxlYXNlczoNCj4NCj4gLSAx
LjAgTTEgd2l0aCBvcmcuc3ByaW5nZnJhbWV3b3JrIGlzIGZpbmUsIGJ1dCB3ZSdsbCBuZWVkIGEg
d2hpbGUgdG8gc2V0DQp1cCB0aGUgbmV3IG1vZHVsZSBhbmQgc3RhYmlsaXplIGJvdGggY29kZWJh
c2UgYW5kIGRvY3VtZW50YXRpb24uDQo+DQo+IC0gU28gSSdtIHNlcmlvdXNseSB0aGlua2luZyBh
Ym91dCBnZXR0aW5nIGEgMC45LjEgd2l0aCBjb20uaW50ZXJmYWNlMjEgb3V0DQoqdG9tb3Jyb3cq
LCBhcyB0aGlzIHNob3VsZCBiZSBqdXN0IGEgZG91YmxlY2xpY2sgb24gb3VyICJyZWxlYXNlIiBB
bnQgdGFyZ2V0DQpwbHVzIGEgZmlsZSB1cGxvYWQgdG8gU291cmNlRm9yZ2UuDQo+DQo+IFRoZSBt
YWluIHJlYXNvbiBpcyB0aGUgSGliZXJuYXRlIHN1cHBvcnQ6IEkndmUgYmVlbiBkaXNjdXNzaW5n
IHRoZSBuZXcNCmZlYXR1cmVzIGZvciBhIHdoaWxlIG9uIHRoZSBIaWJlcm5hdGUgZm9ydW1zIGFu
ZCBpbiB0aGUgQ29tbXVuaXR5IEFyZWENCmFydGljbGUuIFRoaXMgaXMgc3RhYmxlLCBzbyBJJ2Qg
cmVhbGx5IGxpa2UgdG8gZ2V0IGEgZHJvcC1pbiByZXBsYWNlbWVudCBmb3INCjAuOSBvdXQgQVNB
UCwgY29udGFpbmluZyBhbGwgdGhhdCBzdHVmZi4NCj4NCj4gT2YgY291cnNlLCB3ZSBtaWdodCBy
ZWxlYXNlIGFuIG9yZy5zcHJpbmdmcmFtZXdvcmsgMS4wIE0xIGluIGEgd2VlayBvciBzbw0KYWxy
ZWFkeSwgYnV0IG1heWJlIGl0IHdpbGwgdGFrZSAyIHdlZWtzIG9yIDMgd2l0aCBhbGwgdGhlIGRv
Y3MsIHNhbXBsZXMsDQp0ZXN0aW5nLiAwLjkuMSBzaG91bGQgYmUganVzdCBhIHNpbXBsZSBwb2lu
dCByZWxlYXNlIGZvciAwLjksIHdpdGhvdXQgYW55DQpoYXNzbGUgaW4gdGVybXMgb2YgdXBkYXRp
bmcuDQo+DQo+IElmIG5vb25lIGhhcyBhbnkgc2VyaW91cyBvYmplY3Rpb25zLCBJJ2xsIHByb2Nl
ZWQgd2l0aCBzdWNoIGEgMC45LjENCnRvbW9ycm93LiBXZSBkb24ndCBuZWVkIGFueSBhbm5vdW5j
ZW1lbnQgSSBndWVzcywganVzdCBvZmZlciBpdCB0byBleGlzdGluZw0KMC45IHVzZXJzIGFuZCBj
dXJyZW50IHByb3NwZWN0cy4NCj4NCj4gRm9yIDEuMCBNMSwgbXkgcGVyc29uYWwgZGVhZGxpbmUg
aXMgZW5kIG9mIEF1Z3VzdCwgYXMgSSdtIGdvbm5hIHNwZW5kIHRoZQ0Kd2hvbGUgb2YgU2VwdGVt
YmVyIGluIEF1c3RyYWxpYS4NCj4NCj4gUmVnYXJkcywNCj4gSnVlcmdlbg0KPg0KPiBQLlMuOiBN
YXJrJ3MgYW5zd2VyIHJlZ2FyZGluZyBIaWJlcm5hdGVUZW1wbGF0ZSBpbiAwLjkgYWN0dWFsbHkg
Y2FtZSBhZnRlcg0KSSBtYWRlIHVwIG15IG1pbmQgb24gdGhpcywgYnV0IGl0IGZpdHMgdGhlIHRv
bmUgbmljZWx5IDstKQ0KPg0KPiBOGEhTXumailspeyhbIFp63ppuIAQ0RCB3JdinNmkXbBEmypkg
eCtsandF6aK7aiB6ejAOJ+WMllrJqXp7Xt2uMNqKdlwTYkogRE4bbSDetWJyS8mrJg0KPiA/xrRd
NCBN2r0gWt63TiBNIDVKIAdqZ+2wq+2woh167b2W7bKXeCVSy6YgKEde7K69aCAgbHEgB3pt2LY/
WCAoHn56dyBYIGLLnT8gB2pn67CiHXrtvZbtspcNCg0KDQo=

Re: [Springframework-developer] Release plan

[Rod J. <rod...@in...>]

An important driver for getting to an org.springframework release,
preferably called 1.0M1, ASAP after 0.91 is that I think it's essential that
any TSS article use the final package structure, as it will be outdated in
weeks otherwise. So we need the package switch to get publicity.

Regards,
Rod

----- Original Message -----
From: <tri...@tr...>
To: "jürgen höller [werk3AT]" <jue...@we...>
Cc: <spr...@li...>
Sent: Wednesday, August 06, 2003 10:53 PM
Subject: Re: [Springframework-developer] Release plan


> Juergen,
>
> I think a 0.9.1 realease with the old com.interface21 package names very
soon is
> fine.  The new CVS module with org.springframework should follow as soon
as we
> can after we cut the 0.9.1 release.  I did a refactor trial run today
using
> IDEA, and was able to get a clean build in less than half an hour.  Then
we can
> update all the docs and anything else that breaks before we release 1.0M1.
>
> Thomas
>
>
>
> -------------------------------------------------------
> This SF.Net email sponsored by: Free pre-built ASP.NET sites including
> Data Reports, E-commerce, Portals, and Forums are available now.
> Download today and enter to win an XBOX or Visual Studio .NET.
>
http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>

Re: [Springframework-developer] Release plan

[<tri...@tr...>]

Juergen,

I think a 0.9.1 realease with the old com.interface21 package names very soon is
fine.  The new CVS module with org.springframework should follow as soon as we
can after we cut the 0.9.1 release.  I did a refactor trial run today using
IDEA, and was able to get a clean build in less than half an hour.  Then we can
update all the docs and anything else that breaks before we release 1.0M1.

Thomas

Re: [Springframework-developer] Release plan

[Colin S. <col...@ex...>]

That sounds reasonable. It would be the last posted milestone with the 
old package naming.

I still think a subsequent org.springframework release asap (in a week 
or so) would be the best choice in terms of reducing pain for the most 
later, given the ramp-up in use that seems to be happening.


jürgen höller [werk3AT] wrote:

>Guys,
> 
>We're getting really delayed here. I originally intended to stick to a 6 week release schedule - release early, release often, isn't it? That's why I changed my mind a bit regarding upcoming releases:
> 
>- 1.0 M1 with org.springframework is fine, but we'll need a while to set up the new module and stabilize both codebase and documentation.
> 
>- So I'm seriously thinking about getting a 0.9.1 with com.interface21 out *tomorrow*, as this should be just a doubleclick on our "release" Ant target plus a file upload to SourceForge.
> 
>The main reason is the Hibernate support: I've been discussing the new features for a while on the Hibernate forums and in the Community Area article. This is stable, so I'd really like to get a drop-in replacement for 0.9 out ASAP, containing all that stuff.
> 
>Of course, we might release an org.springframework 1.0 M1 in a week or so already, but maybe it will take 2 weeks or 3 with all the docs, samples, testing. 0.9.1 should be just a simple point release for 0.9, without any hassle in terms of updating.
> 
>If noone has any serious objections, I'll proceed with such a 0.9.1 tomorrow. We don't need any announcement I guess, just offer it to existing 0.9 users and current prospects.
> 
>For 1.0 M1, my personal deadline is end of August, as I'm gonna spend the whole of September in Australia.
> 
>Regards,
>Juergen
> 
>P.S.: Mark's answer regarding HibernateTemplate in 0.9 actually came after I made up my mind on this, but it fits the tone nicely ;-)
> 
>

[Springframework-developer] Release plan

[<jue...@we...>]

R3V5cywNCiANCldlJ3JlIGdldHRpbmcgcmVhbGx5IGRlbGF5ZWQgaGVyZS4gSSBvcmlnaW5hbGx5
IGludGVuZGVkIHRvIHN0aWNrIHRvIGEgNiB3ZWVrIHJlbGVhc2Ugc2NoZWR1bGUgLSByZWxlYXNl
IGVhcmx5LCByZWxlYXNlIG9mdGVuLCBpc24ndCBpdD8gVGhhdCdzIHdoeSBJIGNoYW5nZWQgbXkg
bWluZCBhIGJpdCByZWdhcmRpbmcgdXBjb21pbmcgcmVsZWFzZXM6DQogDQotIDEuMCBNMSB3aXRo
IG9yZy5zcHJpbmdmcmFtZXdvcmsgaXMgZmluZSwgYnV0IHdlJ2xsIG5lZWQgYSB3aGlsZSB0byBz
ZXQgdXAgdGhlIG5ldyBtb2R1bGUgYW5kIHN0YWJpbGl6ZSBib3RoIGNvZGViYXNlIGFuZCBkb2N1
bWVudGF0aW9uLg0KIA0KLSBTbyBJJ20gc2VyaW91c2x5IHRoaW5raW5nIGFib3V0IGdldHRpbmcg
YSAwLjkuMSB3aXRoIGNvbS5pbnRlcmZhY2UyMSBvdXQgKnRvbW9ycm93KiwgYXMgdGhpcyBzaG91
bGQgYmUganVzdCBhIGRvdWJsZWNsaWNrIG9uIG91ciAicmVsZWFzZSIgQW50IHRhcmdldCBwbHVz
IGEgZmlsZSB1cGxvYWQgdG8gU291cmNlRm9yZ2UuDQogDQpUaGUgbWFpbiByZWFzb24gaXMgdGhl
IEhpYmVybmF0ZSBzdXBwb3J0OiBJJ3ZlIGJlZW4gZGlzY3Vzc2luZyB0aGUgbmV3IGZlYXR1cmVz
IGZvciBhIHdoaWxlIG9uIHRoZSBIaWJlcm5hdGUgZm9ydW1zIGFuZCBpbiB0aGUgQ29tbXVuaXR5
IEFyZWEgYXJ0aWNsZS4gVGhpcyBpcyBzdGFibGUsIHNvIEknZCByZWFsbHkgbGlrZSB0byBnZXQg
YSBkcm9wLWluIHJlcGxhY2VtZW50IGZvciAwLjkgb3V0IEFTQVAsIGNvbnRhaW5pbmcgYWxsIHRo
YXQgc3R1ZmYuDQogDQpPZiBjb3Vyc2UsIHdlIG1pZ2h0IHJlbGVhc2UgYW4gb3JnLnNwcmluZ2Zy
YW1ld29yayAxLjAgTTEgaW4gYSB3ZWVrIG9yIHNvIGFscmVhZHksIGJ1dCBtYXliZSBpdCB3aWxs
IHRha2UgMiB3ZWVrcyBvciAzIHdpdGggYWxsIHRoZSBkb2NzLCBzYW1wbGVzLCB0ZXN0aW5nLiAw
LjkuMSBzaG91bGQgYmUganVzdCBhIHNpbXBsZSBwb2ludCByZWxlYXNlIGZvciAwLjksIHdpdGhv
dXQgYW55IGhhc3NsZSBpbiB0ZXJtcyBvZiB1cGRhdGluZy4NCiANCklmIG5vb25lIGhhcyBhbnkg
c2VyaW91cyBvYmplY3Rpb25zLCBJJ2xsIHByb2NlZWQgd2l0aCBzdWNoIGEgMC45LjEgdG9tb3Jy
b3cuIFdlIGRvbid0IG5lZWQgYW55IGFubm91bmNlbWVudCBJIGd1ZXNzLCBqdXN0IG9mZmVyIGl0
IHRvIGV4aXN0aW5nIDAuOSB1c2VycyBhbmQgY3VycmVudCBwcm9zcGVjdHMuDQogDQpGb3IgMS4w
IE0xLCBteSBwZXJzb25hbCBkZWFkbGluZSBpcyBlbmQgb2YgQXVndXN0LCBhcyBJJ20gZ29ubmEg
c3BlbmQgdGhlIHdob2xlIG9mIFNlcHRlbWJlciBpbiBBdXN0cmFsaWEuDQogDQpSZWdhcmRzLA0K
SnVlcmdlbg0KIA0KUC5TLjogTWFyaydzIGFuc3dlciByZWdhcmRpbmcgSGliZXJuYXRlVGVtcGxh
dGUgaW4gMC45IGFjdHVhbGx5IGNhbWUgYWZ0ZXIgSSBtYWRlIHVwIG15IG1pbmQgb24gdGhpcywg
YnV0IGl0IGZpdHMgdGhlIHRvbmUgbmljZWx5IDstKQ0KIA0K

RE: [Springframework-developer] Suggestion for a callback implementation.

[Mark P. <mar...@co...>]

Hi,

Thanks, that is a better way, I was only looking at 0.9.

- Mark


-----Original Message-----
From: j=FCrgen h=F6ller [werk3AT] [mailto:jue...@we...]=20
Sent: Wednesday, August 06, 2003 2:29 AM
To: Mark Pollack; spr...@li...
Subject: Re: [Springframework-developer] Suggestion for a callback
implementation.


Hi Mark,
=20
It's easier to use an inner class and simply access a final objectToSave
parameter of the surrounding method, a la:
=20
public void saveMyObject(final MyObject objectToSave) {
  hibernateTemplate.execute(new HibernateCallback() {
    public Object doInHibernate(Session session) throws
HibernateException {
      session.saveOrUpdate(objectToSave);
      return null;
    }
  });
}
=20
HibernateTemplate already provides convenience methods for such
single-step actions since mid-July (after 0.9, but in CVS for a while),
like:
=20
  hibernateTemplate.saveOrUpdate(objectToSave);
  hibernateTemplate.find(query)
=20
etc. The goal is to avoid the overhead of having to write a callback
implementation for just a single line of Hibernate persistence code.
This works quite nicely in practice, especially in combination with
HibernateTransactionManager and JtaTransactionManager that make
HibernateTemplate actions reuse the same Session instance within a whole
transaction.
=20
BTW in my DAOs, I still prefer to have strongly-typed methods not only
for find but for load and store too (like for "MyObject" above), for
clearness of the API, and to keep the option of alternative
implementations with plain JDBC. In a Hibernate version of a DAO, such
methods are often implemented as one-liners with HibernateTemplate's
convenience methods.
=20
Regards,
Juergen
=20
=20

	-----Urspr=FCngliche Nachricht-----=20
	Von: Mark Pollack [mailto:mar...@co...]=20
	Gesendet: Mi 06.08.2003 02:34=20
	An: spr...@li...=20
	Cc:=20
	Betreff: [Springframework-developer] Suggestion for a callback
implementation.
=09
=09

	Hi,
=09
	I was playing around with spring and hibernate and ended up
writing a
	HibernateSaveCallback class that would seem to be generally
useful.  It
	goes something like this, though there are many variations,
maybe to the
	point of parameterizing which method gets called on the session,
passing
	object arrays in the ctor...etc.
=09
	public class HibernateSaveCallback implements HibernateCallback
{
=09
	    private Object _object;
=09
	    public HibernateSaveCallback(Object objectToSave) {
	        _object =3D objectToSave;      =20
	    }
=09
	    public Object doInHibernate(Session session)
	        throws HibernateException, RuntimeException {
	        session.save(_object);
	        return _object;
	    }
=09
	}
=09
=09
	How do people generally handle saving to hibernate using the
	HibernateTemplate in this case?
=09
	Cheers,
	Mark
=09
=09
=09
=09
	-------------------------------------------------------
	This SF.Net email sponsored by: Free pre-built ASP.NET sites
including
	Data Reports, E-commerce, Portals, and Forums are available now.
	Download today and enter to win an XBOX or Visual Studio .NET.
=09
http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01
/01
	_______________________________________________
	Springframework-developer mailing list
	Spr...@li...
=09
https://lists.sourceforge.net/lists/listinfo/springframework-developer
=09

[Springframework-developer] Velocity configuration patch (MVC framework)

[<dar...@hs...>]

I know you guys are busy with imminent package renames and releases, so
apologies in advance if this is the wrong time to be sending patches!

Attached is a class that extends
com.interface21.web.servlet.view.velocity.VelocityConfigurer in order to
permit velocity templates to be portably loaded from within the WAR without
having them in the source tree (and thereby the classpath).  The overridden
initApplicationContext() method prefixes the template path root with the
real path to the WAR root.  The javadoc for the class should make it clear.

In order for this to work, the superclass (VelocityConfigurer) needs to
have the location field promoted from private to protected.  The only
alternative would be to override the setLocation() method in
WarVelocityConfigurer too which is the wrong way to do it I think.  The
very trivial patch file for this change is also attached.

The code relies on the web container using exploded WAR files.  Tomcat and
WebSphere both do by default, but I'm not sure that WebLogic does.

Both changes are based on the 0.9 release (I've no access to CVS at present
to see if updates are available to this part of Spring) and have been
tested successfully in the following locations:

WebSphere 4.0.4 on Windows
WebSphere 5.0 on Windows
Tomcat 4.1.18 on Windows
Tomcat 4.1.24 on Linux

Regards,

Darren Davison
CIBM Intranet Team
int> 799 19431
ext> +44 (0)20 7991 9431

(See attached file: WarVelocityConfigurer.java)(See attached file:
VelocityConfigurer.patch)


_____________________________________________________

This transmission has been issued by a member of the HSBC Group 
"HSBC" for the information of the addressee only and should not be 
reproduced and / or distributed to any other person. Each page attached 
hereto must be read in conjunction with any disclaimer which forms part 
of it. Unless otherwise stated, this transmission is neither an offer nor the 
solicitation of an offer to sell or purchase any investment. Its contents are 
based on information obtained from sources believed to be reliable but
HSBC makes no representation and accepts no responsibility or liability as 
to its completeness or accuracy.

Re: [Springframework-developer] Suggestion for a callback implementation.

[<jue...@we...>]

SGkgTWFyaywNCiANCkl0J3MgZWFzaWVyIHRvIHVzZSBhbiBpbm5lciBjbGFzcyBhbmQgc2ltcGx5
IGFjY2VzcyBhIGZpbmFsIG9iamVjdFRvU2F2ZSBwYXJhbWV0ZXIgb2YgdGhlIHN1cnJvdW5kaW5n
IG1ldGhvZCwgYSBsYToNCiANCnB1YmxpYyB2b2lkIHNhdmVNeU9iamVjdChmaW5hbCBNeU9iamVj
dCBvYmplY3RUb1NhdmUpIHsNCiAgaGliZXJuYXRlVGVtcGxhdGUuZXhlY3V0ZShuZXcgSGliZXJu
YXRlQ2FsbGJhY2soKSB7DQogICAgcHVibGljIE9iamVjdCBkb0luSGliZXJuYXRlKFNlc3Npb24g
c2Vzc2lvbikgdGhyb3dzIEhpYmVybmF0ZUV4Y2VwdGlvbiB7DQogICAgICBzZXNzaW9uLnNhdmVP
clVwZGF0ZShvYmplY3RUb1NhdmUpOw0KICAgICAgcmV0dXJuIG51bGw7DQogICAgfQ0KICB9KTsN
Cn0NCiANCkhpYmVybmF0ZVRlbXBsYXRlIGFscmVhZHkgcHJvdmlkZXMgY29udmVuaWVuY2UgbWV0
aG9kcyBmb3Igc3VjaCBzaW5nbGUtc3RlcCBhY3Rpb25zIHNpbmNlIG1pZC1KdWx5IChhZnRlciAw
LjksIGJ1dCBpbiBDVlMgZm9yIGEgd2hpbGUpLCBsaWtlOg0KIA0KICBoaWJlcm5hdGVUZW1wbGF0
ZS5zYXZlT3JVcGRhdGUob2JqZWN0VG9TYXZlKTsNCiAgaGliZXJuYXRlVGVtcGxhdGUuZmluZChx
dWVyeSkNCiANCmV0Yy4gVGhlIGdvYWwgaXMgdG8gYXZvaWQgdGhlIG92ZXJoZWFkIG9mIGhhdmlu
ZyB0byB3cml0ZSBhIGNhbGxiYWNrIGltcGxlbWVudGF0aW9uIGZvciBqdXN0IGEgc2luZ2xlIGxp
bmUgb2YgSGliZXJuYXRlIHBlcnNpc3RlbmNlIGNvZGUuIFRoaXMgd29ya3MgcXVpdGUgbmljZWx5
IGluIHByYWN0aWNlLCBlc3BlY2lhbGx5IGluIGNvbWJpbmF0aW9uIHdpdGggSGliZXJuYXRlVHJh
bnNhY3Rpb25NYW5hZ2VyIGFuZCBKdGFUcmFuc2FjdGlvbk1hbmFnZXIgdGhhdCBtYWtlIEhpYmVy
bmF0ZVRlbXBsYXRlIGFjdGlvbnMgcmV1c2UgdGhlIHNhbWUgU2Vzc2lvbiBpbnN0YW5jZSB3aXRo
aW4gYSB3aG9sZSB0cmFuc2FjdGlvbi4NCiANCkJUVyBpbiBteSBEQU9zLCBJIHN0aWxsIHByZWZl
ciB0byBoYXZlIHN0cm9uZ2x5LXR5cGVkIG1ldGhvZHMgbm90IG9ubHkgZm9yIGZpbmQgYnV0IGZv
ciBsb2FkIGFuZCBzdG9yZSB0b28gKGxpa2UgZm9yICJNeU9iamVjdCIgYWJvdmUpLCBmb3IgY2xl
YXJuZXNzIG9mIHRoZSBBUEksIGFuZCB0byBrZWVwIHRoZSBvcHRpb24gb2YgYWx0ZXJuYXRpdmUg
aW1wbGVtZW50YXRpb25zIHdpdGggcGxhaW4gSkRCQy4gSW4gYSBIaWJlcm5hdGUgdmVyc2lvbiBv
ZiBhIERBTywgc3VjaCBtZXRob2RzIGFyZSBvZnRlbiBpbXBsZW1lbnRlZCBhcyBvbmUtbGluZXJz
IHdpdGggSGliZXJuYXRlVGVtcGxhdGUncyBjb252ZW5pZW5jZSBtZXRob2RzLg0KIA0KUmVnYXJk
cywNCkp1ZXJnZW4NCiANCiANCg0KCS0tLS0tVXJzcHLDvG5nbGljaGUgTmFjaHJpY2h0LS0tLS0g
DQoJVm9uOiBNYXJrIFBvbGxhY2sgW21haWx0bzptYXJrLnBvbGxhY2tAY29kZXN0cmVldC5jb21d
IA0KCUdlc2VuZGV0OiBNaSAwNi4wOC4yMDAzIDAyOjM0IA0KCUFuOiBzcHJpbmdmcmFtZXdvcmst
ZGV2ZWxvcGVyQGxpc3RzLnNvdXJjZWZvcmdlLm5ldCANCglDYzogDQoJQmV0cmVmZjogW1Nwcmlu
Z2ZyYW1ld29yay1kZXZlbG9wZXJdIFN1Z2dlc3Rpb24gZm9yIGEgY2FsbGJhY2sgaW1wbGVtZW50
YXRpb24uDQoJDQoJDQoNCglIaSwNCgkNCglJIHdhcyBwbGF5aW5nIGFyb3VuZCB3aXRoIHNwcmlu
ZyBhbmQgaGliZXJuYXRlIGFuZCBlbmRlZCB1cCB3cml0aW5nIGENCglIaWJlcm5hdGVTYXZlQ2Fs
bGJhY2sgY2xhc3MgdGhhdCB3b3VsZCBzZWVtIHRvIGJlIGdlbmVyYWxseSB1c2VmdWwuICBJdA0K
CWdvZXMgc29tZXRoaW5nIGxpa2UgdGhpcywgdGhvdWdoIHRoZXJlIGFyZSBtYW55IHZhcmlhdGlv
bnMsIG1heWJlIHRvIHRoZQ0KCXBvaW50IG9mIHBhcmFtZXRlcml6aW5nIHdoaWNoIG1ldGhvZCBn
ZXRzIGNhbGxlZCBvbiB0aGUgc2Vzc2lvbiwgcGFzc2luZw0KCW9iamVjdCBhcnJheXMgaW4gdGhl
IGN0b3IuLi5ldGMuDQoJDQoJcHVibGljIGNsYXNzIEhpYmVybmF0ZVNhdmVDYWxsYmFjayBpbXBs
ZW1lbnRzIEhpYmVybmF0ZUNhbGxiYWNrIHsNCgkNCgkgICAgcHJpdmF0ZSBPYmplY3QgX29iamVj
dDsNCgkNCgkgICAgcHVibGljIEhpYmVybmF0ZVNhdmVDYWxsYmFjayhPYmplY3Qgb2JqZWN0VG9T
YXZlKSB7DQoJICAgICAgICBfb2JqZWN0ID0gb2JqZWN0VG9TYXZlOyAgICAgICANCgkgICAgfQ0K
CQ0KCSAgICBwdWJsaWMgT2JqZWN0IGRvSW5IaWJlcm5hdGUoU2Vzc2lvbiBzZXNzaW9uKQ0KCSAg
ICAgICAgdGhyb3dzIEhpYmVybmF0ZUV4Y2VwdGlvbiwgUnVudGltZUV4Y2VwdGlvbiB7DQoJICAg
ICAgICBzZXNzaW9uLnNhdmUoX29iamVjdCk7DQoJICAgICAgICByZXR1cm4gX29iamVjdDsNCgkg
ICAgfQ0KCQ0KCX0NCgkNCgkNCglIb3cgZG8gcGVvcGxlIGdlbmVyYWxseSBoYW5kbGUgc2F2aW5n
IHRvIGhpYmVybmF0ZSB1c2luZyB0aGUNCglIaWJlcm5hdGVUZW1wbGF0ZSBpbiB0aGlzIGNhc2U/
DQoJDQoJQ2hlZXJzLA0KCU1hcmsNCgkNCgkNCgkNCgkNCgktLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoJVGhpcyBTRi5OZXQgZW1haWwgc3Bv
bnNvcmVkIGJ5OiBGcmVlIHByZS1idWlsdCBBU1AuTkVUIHNpdGVzIGluY2x1ZGluZw0KCURhdGEg
UmVwb3J0cywgRS1jb21tZXJjZSwgUG9ydGFscywgYW5kIEZvcnVtcyBhcmUgYXZhaWxhYmxlIG5v
dy4NCglEb3dubG9hZCB0b2RheSBhbmQgZW50ZXIgdG8gd2luIGFuIFhCT1ggb3IgVmlzdWFsIFN0
dWRpbyAuTkVULg0KCWh0dHA6Ly9hc3BuZXQuY2xpY2stdXJsLmNvbS9nby9wc2EwMDEwMDAwM2F2
ZS9kaXJlY3Q7YXQuYXNwbmV0XzA3MjMwM18wMS8wMQ0KCV9fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fDQoJU3ByaW5nZnJhbWV3b3JrLWRldmVsb3BlciBtYWls
aW5nIGxpc3QNCglTcHJpbmdmcmFtZXdvcmstZGV2ZWxvcGVyQGxpc3RzLnNvdXJjZWZvcmdlLm5l
dA0KCWh0dHBzOi8vbGlzdHMuc291cmNlZm9yZ2UubmV0L2xpc3RzL2xpc3RpbmZvL3NwcmluZ2Zy
YW1ld29yay1kZXZlbG9wZXINCgkNCg0K

[Springframework-developer] Suggestion for a callback implementation.

[Mark P. <mar...@co...>]

Hi,

I was playing around with spring and hibernate and ended up writing a
HibernateSaveCallback class that would seem to be generally useful.  It
goes something like this, though there are many variations, maybe to the
point of parameterizing which method gets called on the session, passing
object arrays in the ctor...etc.

public class HibernateSaveCallback implements HibernateCallback {

    private Object _object;

    public HibernateSaveCallback(Object objectToSave) {
        _object = objectToSave;        
    }

    public Object doInHibernate(Session session)
        throws HibernateException, RuntimeException {
        session.save(_object);
        return _object;
    }

}


How do people generally handle saving to hibernate using the
HibernateTemplate in this case?

Cheers,
Mark
 

Re: [Springframework-developer] Spring, EJBs and XDoclet

[<tri...@tr...>]

It just dawned on me that I should probably specify the name as
'/my-service-context.xml' - not the first time I've made this mistake, and
probably not the last :-)

Thomas

> All,
> 
> Now for the next question - where do you put the ejb-context.xml file on
> WebLogic 8.1?
> 
> I have tried at the root of my EJB class directory and I have also tried
> APP-INF/classes.  No luck so far.
> 
> I am deploying in an exploded directory structure with an enterprise app
> directory that includes a directory for my EJB.
> 
> I keep getting this error:
> 
> javax.ejb.CreateException: Cannot load bean factory path
> 'my-service-context.xml'
> 
> This file exists as 
> 
C:\bea\user_projects\domains\mydomain\applications\MyApp\MyEJB\my-service-context.xml
> 
> as well as
> 
>
C:\bea\user_projects\domains\mydomain\applications\MyApp\APP-INF\classes\my-service-context.xml
> 
> Any ideas?
> 
> 
> Thomas
> 

Re: [Springframework-developer] Spring, EJBs and XDoclet

[<tri...@tr...>]

All,

Now for the next question - where do you put the ejb-context.xml file on
WebLogic 8.1?

I have tried at the root of my EJB class directory and I have also tried
APP-INF/classes.  No luck so far.

I am deploying in an exploded directory structure with an enterprise app
directory that includes a directory for my EJB.

I keep getting this error:

javax.ejb.CreateException: Cannot load bean factory path 'my-service-context.xml'

This file exists as 
 C:\bea\user_projects\domains\mydomain\applications\MyApp\MyEJB\my-service-context.xml

as well as

C:\bea\user_projects\domains\mydomain\applications\MyApp\APP-INF\classes\my-service-context.xml

Any ideas?


Thomas

Re: [Springframework-developer] Spring, EJBs and XDoclet

[<tri...@tr...>]

Timo,

Brilliant.  This solved my problem.

Thanks a lot.

Thomas


> Hi!
> 
> I had the very same problem. Solved it as follows:
> 
> /*
>  * HelloWorldBean.java
>  *
>  * Created on 23. Juli 2003, 17:43
>  */
> 
> package helloworldapp.ejb;
> 
> /**
>  * A simple HelloWorld SLSB.
>  *
>  * @author  Timo Verhoeven
>  *
>  * @ejb.bean
>  *    type="Stateless"
>  *    view-type="both"
>  *    name="HelloWorld"
>  * @ejb.transaction
>  *    type="Required"
>  * @ejb.interface
>  *    extends="javax.ejb.EJBObject"
>  *    local-extends="javax.ejb.EJBLocalObject"
>  * @ejb.home
>  *    extends="javax.ejb.EJBHome"
>  *    local-extends="javax.ejb.EJBLocalHome"
>  */
> public class HelloWorldEJB extends 
> com.interface21.ejb.support.AbstractStatelessSessionBean {
>   
>   /**
>    * @ejb.interface-method
>    */
>   public String sayHello(String name) {
>     return "Hello, " + name + "!";
>   }
>   
>   /**
>    * @ejb.create-method
>    */
>   public void ejbCreate() throws javax.ejb.CreateException {
>   }
>   
> }
> 
> Hope it helps,
> 
> Timo
> 
> Am Dienstag, 5. August 2003 18:33 schrieb tri...@tr...:
> > All,
> >
> > I am extending the
> > com.interface21.ejb.support.AbstractStatelessSessionBean class for my
> > SLSB.  I'm also trying to use XDoclet, but the home/remote interfaces
> > that are generated insists on extending some phantom Spring
> > interfaces and I can not figure out how to get XDoclet to extend the
> > regular javax.ejb.EJBHome and javax.ejb.EJBObject.
> >
> > This is what I have:
> >
> > public class MyServiceBean
> >    extends com.interface21.ejb.support.AbstractStatelessSessionBean
> >
> >
> > This is what I get:
> >
> > public interface MyServiceHome
> >    extends com.interface21.ejb.support.AbstractStatelessSessionHome
> >
> > public interface MyService
> >    extends com.interface21.ejb.support.AbstractStatelessSession
> >
> >
> > Anybody using XDOclet together with Spring?  Any ideas?
> >
> > Thomas
> >
> >
> >
> >
> > -------------------------------------------------------
> > This SF.Net email sponsored by: Free pre-built ASP.NET sites
> > including Data Reports, E-commerce, Portals, and Forums are available
> > now. Download today and enter to win an XBOX or Visual Studio .NET.
> > http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303
> >_01/01 _______________________________________________
> > Springframework-developer mailing list
> > Spr...@li...
> > https://lists.sourceforge.net/lists/listinfo/springframework-develope
> >r
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email sponsored by: Free pre-built ASP.NET sites including
> Data Reports, E-commerce, Portals, and Forums are available now.
> Download today and enter to win an XBOX or Visual Studio .NET.
> http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
> 

Re: [Springframework-developer] Spring, EJBs and XDoclet

[Timo V. <sic...@gm...>]

Hi!

I had the very same problem. Solved it as follows:

/*
 * HelloWorldBean.java
 *
 * Created on 23. Juli 2003, 17:43
 */

package helloworldapp.ejb;

/**
 * A simple HelloWorld SLSB.
 *
 * @author  Timo Verhoeven
 *
 * @ejb.bean
 *    type="Stateless"
 *    view-type="both"
 *    name="HelloWorld"
 * @ejb.transaction
 *    type="Required"
 * @ejb.interface
 *    extends="javax.ejb.EJBObject"
 *    local-extends="javax.ejb.EJBLocalObject"
 * @ejb.home
 *    extends="javax.ejb.EJBHome"
 *    local-extends="javax.ejb.EJBLocalHome"
 */
public class HelloWorldEJB extends 
com.interface21.ejb.support.AbstractStatelessSessionBean {
  
  /**
   * @ejb.interface-method
   */
  public String sayHello(String name) {
    return "Hello, " + name + "!";
  }
  
  /**
   * @ejb.create-method
   */
  public void ejbCreate() throws javax.ejb.CreateException {
  }
  
}

Hope it helps,

Timo

Am Dienstag, 5. August 2003 18:33 schrieb tri...@tr...:
> All,
>
> I am extending the
> com.interface21.ejb.support.AbstractStatelessSessionBean class for my
> SLSB.  I'm also trying to use XDoclet, but the home/remote interfaces
> that are generated insists on extending some phantom Spring
> interfaces and I can not figure out how to get XDoclet to extend the
> regular javax.ejb.EJBHome and javax.ejb.EJBObject.
>
> This is what I have:
>
> public class MyServiceBean
>    extends com.interface21.ejb.support.AbstractStatelessSessionBean
>
>
> This is what I get:
>
> public interface MyServiceHome
>    extends com.interface21.ejb.support.AbstractStatelessSessionHome
>
> public interface MyService
>    extends com.interface21.ejb.support.AbstractStatelessSession
>
>
> Anybody using XDOclet together with Spring?  Any ideas?
>
> Thomas
>
>
>
>
> -------------------------------------------------------
> This SF.Net email sponsored by: Free pre-built ASP.NET sites
> including Data Reports, E-commerce, Portals, and Forums are available
> now. Download today and enter to win an XBOX or Visual Studio .NET.
> http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303
>_01/01 _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-develope
>r