Menu
▾
▴
springframework-developer
|
From: Mason, R. <ros...@vi...> - 2005-01-27 23:48:30
|
SGkgSG93YXJkLA0KIA0KV2hhdCBpcyB0aGUgdXNlIGNhc2UgZm9yIGludGVncmF0aW5nIEhpdmVN aW5kIGFuZCBTcHJpbmc/ICBJIG11c3QgYWRtaXQgSSBoYXZlbid0IGhhZCBhIGNoYW5jZSB0byBn ZXQgYSBnb29kIGxvb2sgYXQgSGl2ZU1pbmQsIGJ1dCBteSB1bmRlcnN0YW5kaW5nIGlzIHRoYXQg aXQgaXMgYSBESSBjb250YWluZXIgdGhhdCBwcm92aWRlcyBzZXJ2aWNlIHdpcmluZyBhbmQgaW50 ZXJjZXB0aW9uLCBtdWNoIGluIHRoZSBzYW1lIHZlaW4gYXMgdGhlIFNwcmluZyBDb250YWluZXIu ICBGcm9tIHRoZSBvdXRzZXQgdGhlIHR3byBjb250YWluZXJzIHNlZW0gdG8gYmUgbXV0YWxseSBl eGNsdXNpdmUgcmF0aGVyIHRoYW4gY29tcGxpbWVudGFyeS4NCiANCkNhbiB5b3Ugc2hlZCBzb21l IGxpZ2h0IG9uIHRoaXMgZm9yIG1lPw0KIA0KQ2hlZXJzLA0KIA0KUm9zcw0KDQoJLS0tLS1Pcmln aW5hbCBNZXNzYWdlLS0tLS0gDQoJRnJvbTogc3ByaW5nZnJhbWV3b3JrLWRldmVsb3Blci1hZG1p bkBsaXN0cy5zb3VyY2Vmb3JnZS5uZXQgb24gYmVoYWxmIG9mIEhvd2FyZCBMZXdpcyBTaGlwIA0K CVNlbnQ6IFdlZCAyNi8wMS8yMDA1IDI6NDYgUE0gDQoJVG86IHNwcmluZ2ZyYW1ld29yay1kZXZl bG9wZXJAbGlzdHMuc291cmNlZm9yZ2UubmV0IA0KCUNjOiANCglTdWJqZWN0OiBbU3ByaW5nZnJh bWV3b3JrLWRldmVsb3Blcl0gU3ByaW5nIC8gSGl2ZU1pbmQgSW50ZWdyYXRpb24NCgkNCgkNCg0K CVNpbmNlIEhpdmVNaW5kIDEuMCwgYW5kIGltcHJvdmVkIGluIEhpdmVNaW5kIDEuMSwgdGhlcmUn cyBiZWVuIGJhc2ljDQoJaW50ZWdyYXRpb24gYmV0d2VlbiBIaXZlTWluZCBhbmQgU3ByaW5nLg0K CQ0KCUF0IHRoZSBjb3JlIG9mIGl0IGlzIHRoZSBhYmlsaXR5IHRvIGRlZmluZSBhIEhpdmVNaW5k IHNlcnZpY2UgaW4gdGVybXMNCglvZiBhIFNwcmluZyBiZWFuIHdpdGhpbiBhIEJlYW5GYWN0b3J5 LiAgVGhlIGVzc2VudGlhbCBjb2RlIGlzOg0KCQ0KCSAgICBwdWJsaWMgT2JqZWN0IGNyZWF0ZUNv cmVTZXJ2aWNlSW1wbGVtZW50YXRpb24oDQoJICAgICAgICAgICAgU2VydmljZUltcGxlbWVudGF0 aW9uRmFjdG9yeVBhcmFtZXRlcnMgZmFjdG9yeVBhcmFtZXRlcnMpDQoJICAgIHsNCgkgICAgICAg IFNwcmluZ0JlYW5QYXJhbWV0ZXIgcCA9IChTcHJpbmdCZWFuUGFyYW1ldGVyKQ0KCWZhY3RvcnlQ YXJhbWV0ZXJzLmdldEZpcnN0UGFyYW1ldGVyKCk7DQoJICAgICAgICBTdHJpbmcgYmVhbk5hbWUg PSBwLmdldE5hbWUoKTsNCgkNCgkgICAgICAgIEJlYW5GYWN0b3J5IGYgPSBwLmdldEJlYW5GYWN0 b3J5KCk7DQoJDQoJICAgICAgICBpZiAoZiA9PSBudWxsKQ0KCSAgICAgICAgICAgIGYgPSBfZGVm YXVsdEJlYW5GYWN0b3J5Ow0KCQ0KCSAgICAgICAgcmV0dXJuIGYuZ2V0QmVhbihiZWFuTmFtZSwg ZmFjdG9yeVBhcmFtZXRlcnMuZ2V0U2VydmljZUludGVyZmFjZSgpKTsNCgkgICAgfQ0KCQ0KCVdp dGggdGhpcywgaXRzIHBvc3NpYmxlIHRvIG9idGFpbiBhIFNwcmluZyBiZWFuIGFuZCB0aGUgY29y ZSBzZXJ2aWNlDQoJaW1wbGVtZW50YXRpb24gb2YgYSBIaXZlTWluZCBzZXJ2aWNlLiAgVGhlIGlt cGxlbWVudGF0aW9uIGNhbiBiZQ0KCWV4dGVuZGVkIHdpdGggaW50ZXJjZXB0b3JzIGFuZCBpbmpl Y3RlZCBpbnRvIG90aGVyIEhpdmVNaW5kIHNlcnZpY2VzLg0KCQ0KCUF0IEphdmFwb2xpcywgSSB0 YWxrZWQgd2l0aCBSb2QgYWJvdXQgaGF2aW5nIHNvbWV0aGluZyBzaW1pbGFyIGdvaW5nDQoJdGhl IG90aGVyIGRpcmVjdGlvbiwgYWxsb3dpbmcgSGl2ZU1pbmQgc2VydmljZXMgdG8gYmUgcmVmZXJl bmNhYmxlDQoJKGFuZCBpbmplY3RhYmxlKSBhcyBTcHJpbmcgYmVhbnMuIEknZCBsaWtlIHRvIHBy b3Zva2UgYSBkaXNjdXNzaW9uIG9uDQoJd2hhdCB0aGF0IHdvdWxkIGxvb2sgbGlrZSwgYW5kIHdo YXQgQVBJIGNoYW5nZXMgd291bGQgYmUgbmVlZGVkIGluDQoJSGl2ZU1pbmQgMS4xIHRvIHN1cHBv cnQgaXQuDQoJDQoJUm9kIHNlZW1lZCB0byB0aGluayAoYW5kIEkgZGlkbid0IGZvbGxvdyB0aGUg cmVhc29uaW5nKSB0aGF0IEhpdmVNaW5kDQoJd291bGQgbmVlZCBhbiBBUEkgdG8gaXRlcmF0ZSBv dmVyIHRoZSBuYW1lcyBvZiBhbGwgc2VydmljZXMuDQoJDQoJSW4gYWRkaXRpb24sIGNvbmZpZ3Vy YXRpb24gZGF0YSAoaW4gZWl0aGVyIExpc3Qgb3IgTWFwIGZvcm0pIGlzIGFsc28NCglxdWl0ZSB2 YWx1YWJsZSBhbmQgc29tZXRoaW5nIHRoYXQgU3ByaW5nIGJlYW5zIHdvdWxkIGxpa2UgdG8gaGF2 ZQ0KCWFjY2VzcyB0by4NCgkNCgktLQ0KCUhvd2FyZCBNLiBMZXdpcyBTaGlwDQoJSW5kZXBlbmRl bnQgSjJFRSAvIE9wZW4tU291cmNlIEphdmEgQ29uc3VsdGFudA0KCUNyZWF0b3IsIEpha2FydGEg VGFwZXN0cnkNCglDcmVhdG9yLCBKYWthcnRhIEhpdmVNaW5kDQoJDQoJUHJvZmVzc2lvbmFsIFRh cGVzdHJ5IHRyYWluaW5nLCBtZW50b3JpbmcsIHN1cHBvcnQNCglhbmQgcHJvamVjdCB3b3JrLiAg aHR0cDovL2hvd2FyZGxld2lzc2hpcC5jb20NCgkNCgkNCgktLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoJVGhpcyBTRi5OZXQgZW1haWwgaXMg c3BvbnNvcmVkIGJ5OiBJbnRlbGxpVklFVyAtLSBJbnRlcmFjdGl2ZSBSZXBvcnRpbmcNCglUb29s IGZvciBvcGVuIHNvdXJjZSBkYXRhYmFzZXMuIENyZWF0ZSBkcmFnLSYtZHJvcCByZXBvcnRzLiBT YXZlIHRpbWUNCglieSBvdmVyIDc1JSEgUHVibGlzaCByZXBvcnRzIG9uIHRoZSB3ZWIuIEV4cG9y dCB0byBET0MsIFhMUywgUlRGLCBldGMuDQoJRG93bmxvYWQgYSBGUkVFIGNvcHkgYXQgaHR0cDov L3d3dy5pbnRlbGxpdmlldy5jb20vZ28vb3Nkbl9ubA0KCV9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQoJU3ByaW5nZnJhbWV3b3JrLWRldmVsb3BlciBtYWls aW5nIGxpc3QNCglTcHJpbmdmcmFtZXdvcmstZGV2ZWxvcGVyQGxpc3RzLnNvdXJjZWZvcmdlLm5l dA0KCWh0dHBzOi8vbGlzdHMuc291cmNlZm9yZ2UubmV0L2xpc3RzL2xpc3RpbmZvL3NwcmluZ2Zy YW1ld29yay1kZXZlbG9wZXINCgkNCg0K |
|
From: Mason, R. <ros...@vi...> - 2005-01-29 06:46:46
|
SG93YXJkLA0KVGhhbmtzIGZvciB0aGUgcmVzcG9uc2UuIEkgYWdyZWUgdGhhdCBpdCB3b3VsZCBi ZSBiZXR0ZXIgdG8gZm9zdGVyIGNvb3BlcmF0aW9uIGFuZCBJIGxvb2sgZm9yd2FyZCB0byBkZWx2 aW5nIGRlZXBlci4NCiANCkNoZWVycywNCiANClJvc3MNCg0KCS0tLS0tT3JpZ2luYWwgTWVzc2Fn ZS0tLS0tIA0KCUZyb206IHNwcmluZ2ZyYW1ld29yay1kZXZlbG9wZXItYWRtaW5AbGlzdHMuc291 cmNlZm9yZ2UubmV0IG9uIGJlaGFsZiBvZiBIb3dhcmQgTGV3aXMgU2hpcCANCglTZW50OiBGcmkg MjgvMDEvMjAwNSAxMjozMyBQTSANCglUbzogc3ByaW5nZnJhbWV3b3JrLWRldmVsb3BlckBsaXN0 cy5zb3VyY2Vmb3JnZS5uZXQgDQoJQ2M6IA0KCVN1YmplY3Q6IFJlOiBbU3ByaW5nZnJhbWV3b3Jr LWRldmVsb3Blcl0gU3ByaW5nIC8gSGl2ZU1pbmQgSW50ZWdyYXRpb24NCgkNCgkNCg0KCVRoaXMg Y29tZXMgdXAgcXVpdGUgYSBiaXQsIHRoZXkgYXJlIHNpbWlsaWFyIGluIGludGVudCBidXQgcXVp dGUNCglkaWZmZXJlbnQgaW4gZXhlY3V0aW9uLg0KCQ0KCS0gSGl2ZU1pbmQgaGFzIGEgdmVyeSBz b3BoaXNpdGljYXRlZCBjb25maWd1cmF0aW9ucyBtb2RlbCAodmVyeQ0KCXNpbWlsYXIgdG8gRWNs aXBzZSBwbHVnaW5zKSBiYXNlZCBvbiBjb25maWd1cmF0aW9uIHBvaW50cyBhbmQNCgljb250cmli dXRpb25zIChmcm9tIG11bHRpcGxlIGxvY2F0aW9ucykNCgktIEhpdmVNaW5kIGlzIHRoZSBpbmZy YXN0cnVjdHVyZSBmb3IgVGFwZXN0cnkgMy4xLCBhbmQgbWFueSBUYXBlc3RyeQ0KCWFwcGxpY2F0 aW9ucyBhbHNvIHVzZSBTcHJpbmcNCgktIEJlY2F1c2UgUm9kIGFuZCBJIChhbmQgdGhlIG90aGVy IFNwcmluZyB0ZWFtIG1lbWJlcidzIEkndmUgdGFsa2VkDQoJdG8pIHdhbnQgdG8gZm9zdGVyIGNv b3BlcmF0aW9uIGFuZCBjb21wYXRhYmlsaXR5IHJhdGhlciB0aGFuDQoJY29tcGV0aXRpb24NCgkN CgkNCglPbiBGcmksIDI4IEphbiAyMDA1IDEwOjQ3OjQ4ICsxMTAwLCBNYXNvbiwgUm9zcyA8cm9z cy5tYXNvbkB2aWduZXR0ZS5jb20+IHdyb3RlOg0KCT4gSGkgSG93YXJkLA0KCT4NCgk+IFdoYXQg aXMgdGhlIHVzZSBjYXNlIGZvciBpbnRlZ3JhdGluZyBIaXZlTWluZCBhbmQgU3ByaW5nPyAgSSBt dXN0IGFkbWl0IEkgaGF2ZW4ndCBoYWQgYSBjaGFuY2UgdG8gZ2V0IGEgZ29vZCBsb29rIGF0IEhp dmVNaW5kLCBidXQgbXkgdW5kZXJzdGFuZGluZyBpcyB0aGF0IGl0IGlzIGEgREkgY29udGFpbmVy IHRoYXQgcHJvdmlkZXMgc2VydmljZSB3aXJpbmcgYW5kIGludGVyY2VwdGlvbiwgbXVjaCBpbiB0 aGUgc2FtZSB2ZWluIGFzIHRoZSBTcHJpbmcgQ29udGFpbmVyLiAgRnJvbSB0aGUgb3V0c2V0IHRo ZSB0d28gY29udGFpbmVycyBzZWVtIHRvIGJlIG11dGFsbHkgZXhjbHVzaXZlIHJhdGhlciB0aGFu IGNvbXBsaW1lbnRhcnkuDQoJPg0KCT4gQ2FuIHlvdSBzaGVkIHNvbWUgbGlnaHQgb24gdGhpcyBm b3IgbWU/DQoJPg0KCT4gQ2hlZXJzLA0KCT4NCgk+IFJvc3MNCgk+DQoJPiAgICAgICAgIC0tLS0t T3JpZ2luYWwgTWVzc2FnZS0tLS0tDQoJPiAgICAgICAgIEZyb206IHNwcmluZ2ZyYW1ld29yay1k ZXZlbG9wZXItYWRtaW5AbGlzdHMuc291cmNlZm9yZ2UubmV0IG9uIGJlaGFsZiBvZiBIb3dhcmQg TGV3aXMgU2hpcA0KCT4gICAgICAgICBTZW50OiBXZWQgMjYvMDEvMjAwNSAyOjQ2IFBNDQoJPiAg ICAgICAgIFRvOiBzcHJpbmdmcmFtZXdvcmstZGV2ZWxvcGVyQGxpc3RzLnNvdXJjZWZvcmdlLm5l dA0KCT4gICAgICAgICBDYzoNCgk+ICAgICAgICAgU3ViamVjdDogW1NwcmluZ2ZyYW1ld29yay1k ZXZlbG9wZXJdIFNwcmluZyAvIEhpdmVNaW5kIEludGVncmF0aW9uDQoJPg0KCT4gICAgICAgICBT aW5jZSBIaXZlTWluZCAxLjAsIGFuZCBpbXByb3ZlZCBpbiBIaXZlTWluZCAxLjEsIHRoZXJlJ3Mg YmVlbiBiYXNpYw0KCT4gICAgICAgICBpbnRlZ3JhdGlvbiBiZXR3ZWVuIEhpdmVNaW5kIGFuZCBT cHJpbmcuDQoJPg0KCT4gICAgICAgICBBdCB0aGUgY29yZSBvZiBpdCBpcyB0aGUgYWJpbGl0eSB0 byBkZWZpbmUgYSBIaXZlTWluZCBzZXJ2aWNlIGluIHRlcm1zDQoJPiAgICAgICAgIG9mIGEgU3By aW5nIGJlYW4gd2l0aGluIGEgQmVhbkZhY3RvcnkuICBUaGUgZXNzZW50aWFsIGNvZGUgaXM6DQoJ Pg0KCT4gICAgICAgICAgICAgcHVibGljIE9iamVjdCBjcmVhdGVDb3JlU2VydmljZUltcGxlbWVu dGF0aW9uKA0KCT4gICAgICAgICAgICAgICAgICAgICBTZXJ2aWNlSW1wbGVtZW50YXRpb25GYWN0 b3J5UGFyYW1ldGVycyBmYWN0b3J5UGFyYW1ldGVycykNCgk+ICAgICAgICAgICAgIHsNCgk+ICAg ICAgICAgICAgICAgICBTcHJpbmdCZWFuUGFyYW1ldGVyIHAgPSAoU3ByaW5nQmVhblBhcmFtZXRl cikNCgk+ICAgICAgICAgZmFjdG9yeVBhcmFtZXRlcnMuZ2V0Rmlyc3RQYXJhbWV0ZXIoKTsNCgk+ ICAgICAgICAgICAgICAgICBTdHJpbmcgYmVhbk5hbWUgPSBwLmdldE5hbWUoKTsNCgk+DQoJPiAg ICAgICAgICAgICAgICAgQmVhbkZhY3RvcnkgZiA9IHAuZ2V0QmVhbkZhY3RvcnkoKTsNCgk+DQoJ PiAgICAgICAgICAgICAgICAgaWYgKGYgPT0gbnVsbCkNCgk+ICAgICAgICAgICAgICAgICAgICAg ZiA9IF9kZWZhdWx0QmVhbkZhY3Rvcnk7DQoJPg0KCT4gICAgICAgICAgICAgICAgIHJldHVybiBm LmdldEJlYW4oYmVhbk5hbWUsIGZhY3RvcnlQYXJhbWV0ZXJzLmdldFNlcnZpY2VJbnRlcmZhY2Uo KSk7DQoJPiAgICAgICAgICAgICB9DQoJPg0KCT4gICAgICAgICBXaXRoIHRoaXMsIGl0cyBwb3Nz aWJsZSB0byBvYnRhaW4gYSBTcHJpbmcgYmVhbiBhbmQgdGhlIGNvcmUgc2VydmljZQ0KCT4gICAg ICAgICBpbXBsZW1lbnRhdGlvbiBvZiBhIEhpdmVNaW5kIHNlcnZpY2UuICBUaGUgaW1wbGVtZW50 YXRpb24gY2FuIGJlDQoJPiAgICAgICAgIGV4dGVuZGVkIHdpdGggaW50ZXJjZXB0b3JzIGFuZCBp bmplY3RlZCBpbnRvIG90aGVyIEhpdmVNaW5kIHNlcnZpY2VzLg0KCT4NCgk+ICAgICAgICAgQXQg SmF2YXBvbGlzLCBJIHRhbGtlZCB3aXRoIFJvZCBhYm91dCBoYXZpbmcgc29tZXRoaW5nIHNpbWls YXIgZ29pbmcNCgk+ICAgICAgICAgdGhlIG90aGVyIGRpcmVjdGlvbiwgYWxsb3dpbmcgSGl2ZU1p bmQgc2VydmljZXMgdG8gYmUgcmVmZXJlbmNhYmxlDQoJPiAgICAgICAgIChhbmQgaW5qZWN0YWJs ZSkgYXMgU3ByaW5nIGJlYW5zLiBJJ2QgbGlrZSB0byBwcm92b2tlIGEgZGlzY3Vzc2lvbiBvbg0K CT4gICAgICAgICB3aGF0IHRoYXQgd291bGQgbG9vayBsaWtlLCBhbmQgd2hhdCBBUEkgY2hhbmdl cyB3b3VsZCBiZSBuZWVkZWQgaW4NCgk+ICAgICAgICAgSGl2ZU1pbmQgMS4xIHRvIHN1cHBvcnQg aXQuDQoJPg0KCT4gICAgICAgICBSb2Qgc2VlbWVkIHRvIHRoaW5rIChhbmQgSSBkaWRuJ3QgZm9s bG93IHRoZSByZWFzb25pbmcpIHRoYXQgSGl2ZU1pbmQNCgk+ICAgICAgICAgd291bGQgbmVlZCBh biBBUEkgdG8gaXRlcmF0ZSBvdmVyIHRoZSBuYW1lcyBvZiBhbGwgc2VydmljZXMuDQoJPg0KCT4g ICAgICAgICBJbiBhZGRpdGlvbiwgY29uZmlndXJhdGlvbiBkYXRhIChpbiBlaXRoZXIgTGlzdCBv ciBNYXAgZm9ybSkgaXMgYWxzbw0KCT4gICAgICAgICBxdWl0ZSB2YWx1YWJsZSBhbmQgc29tZXRo aW5nIHRoYXQgU3ByaW5nIGJlYW5zIHdvdWxkIGxpa2UgdG8gaGF2ZQ0KCT4gICAgICAgICBhY2Nl c3MgdG8uDQoJPg0KCT4gICAgICAgICAtLQ0KCT4gICAgICAgICBIb3dhcmQgTS4gTGV3aXMgU2hp cA0KCT4gICAgICAgICBJbmRlcGVuZGVudCBKMkVFIC8gT3Blbi1Tb3VyY2UgSmF2YSBDb25zdWx0 YW50DQoJPiAgICAgICAgIENyZWF0b3IsIEpha2FydGEgVGFwZXN0cnkNCgk+ICAgICAgICAgQ3Jl YXRvciwgSmFrYXJ0YSBIaXZlTWluZA0KCT4NCgk+ICAgICAgICAgUHJvZmVzc2lvbmFsIFRhcGVz dHJ5IHRyYWluaW5nLCBtZW50b3JpbmcsIHN1cHBvcnQNCgk+ICAgICAgICAgYW5kIHByb2plY3Qg d29yay4gIGh0dHA6Ly9ob3dhcmRsZXdpc3NoaXAuY29tDQoJPg0KCT4gICAgICAgIA0KCT4gICAg ICAgICAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tDQoJPiAgICAgICAgIFRoaXMgU0YuTmV0IGVtYWlsIGlzIHNwb25zb3JlZCBieTogSW50ZWxs aVZJRVcgLS0gSW50ZXJhY3RpdmUgUmVwb3J0aW5nDQoJPiAgICAgICAgIFRvb2wgZm9yIG9wZW4g c291cmNlIGRhdGFiYXNlcy4gQ3JlYXRlIGRyYWctJi1kcm9wIHJlcG9ydHMuIFNhdmUgdGltZQ0K CT4gICAgICAgICBieSBvdmVyIDc1JSEgUHVibGlzaCByZXBvcnRzIG9uIHRoZSB3ZWIuIEV4cG9y dCB0byBET0MsIFhMUywgUlRGLCBldGMuDQoJPiAgICAgICAgIERvd25sb2FkIGEgRlJFRSBjb3B5 IGF0IGh0dHA6Ly93d3cuaW50ZWxsaXZpZXcuY29tL2dvL29zZG5fbmwNCgk+ICAgICAgICAgX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCgk+ICAgICAgICAg U3ByaW5nZnJhbWV3b3JrLWRldmVsb3BlciBtYWlsaW5nIGxpc3QNCgk+ICAgICAgICAgU3ByaW5n ZnJhbWV3b3JrLWRldmVsb3BlckBsaXN0cy5zb3VyY2Vmb3JnZS5uZXQNCgk+ICAgICAgICAgaHR0 cHM6Ly9saXN0cy5zb3VyY2Vmb3JnZS5uZXQvbGlzdHMvbGlzdGluZm8vc3ByaW5nZnJhbWV3b3Jr LWRldmVsb3Blcg0KCT4NCgk+DQoJPg0KCQ0KCQ0KCS0tDQoJSG93YXJkIE0uIExld2lzIFNoaXAN CglJbmRlcGVuZGVudCBKMkVFIC8gT3Blbi1Tb3VyY2UgSmF2YSBDb25zdWx0YW50DQoJQ3JlYXRv ciwgSmFrYXJ0YSBUYXBlc3RyeQ0KCUNyZWF0b3IsIEpha2FydGEgSGl2ZU1pbmQNCgkNCglQcm9m ZXNzaW9uYWwgVGFwZXN0cnkgdHJhaW5pbmcsIG1lbnRvcmluZywgc3VwcG9ydA0KCWFuZCBwcm9q ZWN0IHdvcmsuICBodHRwOi8vaG93YXJkbGV3aXNzaGlwLmNvbQ0KCQ0KCQ0KCS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCglUaGlzIFNGLk5l dCBlbWFpbCBpcyBzcG9uc29yZWQgYnk6IEludGVsbGlWSUVXIC0tIEludGVyYWN0aXZlIFJlcG9y dGluZw0KCVRvb2wgZm9yIG9wZW4gc291cmNlIGRhdGFiYXNlcy4gQ3JlYXRlIGRyYWctJi1kcm9w IHJlcG9ydHMuIFNhdmUgdGltZQ0KCWJ5IG92ZXIgNzUlISBQdWJsaXNoIHJlcG9ydHMgb24gdGhl IHdlYi4gRXhwb3J0IHRvIERPQywgWExTLCBSVEYsIGV0Yy4NCglEb3dubG9hZCBhIEZSRUUgY29w eSBhdCBodHRwOi8vd3d3LmludGVsbGl2aWV3LmNvbS9nby9vc2RuX25sDQoJX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCglTcHJpbmdmcmFtZXdvcmstZGV2 ZWxvcGVyIG1haWxpbmcgbGlzdA0KCVNwcmluZ2ZyYW1ld29yay1kZXZlbG9wZXJAbGlzdHMuc291 cmNlZm9yZ2UubmV0DQoJaHR0cHM6Ly9saXN0cy5zb3VyY2Vmb3JnZS5uZXQvbGlzdHMvbGlzdGlu Zm8vc3ByaW5nZnJhbWV3b3JrLWRldmVsb3Blcg0KCQ0KDQo= |
|
From: Howard L. S. <hl...@gm...> - 2005-01-28 12:33:28
|
This comes up quite a bit, they are similiar in intent but quite
different in execution.
- HiveMind has a very sophisiticated configurations model (very
similar to Eclipse plugins) based on configuration points and
contributions (from multiple locations)
- HiveMind is the infrastructure for Tapestry 3.1, and many Tapestry
applications also use Spring
- Because Rod and I (and the other Spring team member's I've talked
to) want to foster cooperation and compatability rather than
competition
On Fri, 28 Jan 2005 10:47:48 +1100, Mason, Ross <ros...@vi...> wrote:
> Hi Howard,
>
> What is the use case for integrating HiveMind and Spring? I must admit I haven't had a chance to get a good look at HiveMind, but my understanding is that it is a DI container that provides service wiring and interception, much in the same vein as the Spring Container. From the outset the two containers seem to be mutally exclusive rather than complimentary.
>
> Can you shed some light on this for me?
>
> Cheers,
>
> Ross
>
> -----Original Message-----
> From: spr...@li... on behalf of Howard Lewis Ship
> Sent: Wed 26/01/2005 2:46 PM
> To: spr...@li...
> Cc:
> Subject: [Springframework-developer] Spring / HiveMind Integration
>
> Since HiveMind 1.0, and improved in HiveMind 1.1, there's been basic
> integration between HiveMind and Spring.
>
> At the core of it is the ability to define a HiveMind service in terms
> of a Spring bean within a BeanFactory. The essential code is:
>
> public Object createCoreServiceImplementation(
> ServiceImplementationFactoryParameters factoryParameters)
> {
> SpringBeanParameter p = (SpringBeanParameter)
> factoryParameters.getFirstParameter();
> String beanName = p.getName();
>
> BeanFactory f = p.getBeanFactory();
>
> if (f == null)
> f = _defaultBeanFactory;
>
> return f.getBean(beanName, factoryParameters.getServiceInterface());
> }
>
> With this, its possible to obtain a Spring bean and the core service
> implementation of a HiveMind service. The implementation can be
> extended with interceptors and injected into other HiveMind services.
>
> At Javapolis, I talked with Rod about having something similar going
> the other direction, allowing HiveMind services to be referencable
> (and injectable) as Spring beans. I'd like to provoke a discussion on
> what that would look like, and what API changes would be needed in
> HiveMind 1.1 to support it.
>
> Rod seemed to think (and I didn't follow the reasoning) that HiveMind
> would need an API to iterate over the names of all services.
>
> In addition, configuration data (in either List or Map form) is also
> quite valuable and something that Spring beans would like to have
> access to.
>
> --
> Howard M. Lewis Ship
> Independent J2EE / Open-Source Java Consultant
> Creator, Jakarta Tapestry
> Creator, Jakarta HiveMind
>
> Professional Tapestry training, mentoring, support
> and project work. http://howardlewisship.com
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
> Tool for open source databases. Create drag-&-drop reports. Save time
> by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
> Download a FREE copy at http://www.intelliview.com/go/osdn_nl
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>
--
Howard M. Lewis Ship
Independent J2EE / Open-Source Java Consultant
Creator, Jakarta Tapestry
Creator, Jakarta HiveMind
Professional Tapestry training, mentoring, support
and project work. http://howardlewisship.com
|
|
From: Rob H. <ro...@ca...> - 2005-01-29 13:11:44
|
Howard,
I think it will be quite simple to integrate HiveMind services into
Spring. As I see it we need a HiveMindRegistryFactoryBean to create the
Registry instance and then a HiveMindServiceFactoryBean that uses the
Registry to lookup a given service. By default the
HiveMindServiceFactoryBean would use the Spring bean name to lookup a
service in the Registry, but users could configure a different service
name using DI. With this mechanism, users can create one instance of
Registry within a Spring application and then access many services from
that Registry.
If I have time today, I'll work on this. If not, I'll work on it next
week some time.
Rob
Howard Lewis Ship wrote:
>This comes up quite a bit, they are similiar in intent but quite
>different in execution.
>
>- HiveMind has a very sophisiticated configurations model (very
>similar to Eclipse plugins) based on configuration points and
>contributions (from multiple locations)
>- HiveMind is the infrastructure for Tapestry 3.1, and many Tapestry
>applications also use Spring
>- Because Rod and I (and the other Spring team member's I've talked
>to) want to foster cooperation and compatability rather than
>competition
>
>
>On Fri, 28 Jan 2005 10:47:48 +1100, Mason, Ross <ros...@vi...> wrote:
>
>
>>Hi Howard,
>>
>>What is the use case for integrating HiveMind and Spring? I must admit I haven't had a chance to get a good look at HiveMind, but my understanding is that it is a DI container that provides service wiring and interception, much in the same vein as the Spring Container. From the outset the two containers seem to be mutally exclusive rather than complimentary.
>>
>>Can you shed some light on this for me?
>>
>>Cheers,
>>
>>Ross
>>
>> -----Original Message-----
>> From: spr...@li... on behalf of Howard Lewis Ship
>> Sent: Wed 26/01/2005 2:46 PM
>> To: spr...@li...
>> Cc:
>> Subject: [Springframework-developer] Spring / HiveMind Integration
>>
>> Since HiveMind 1.0, and improved in HiveMind 1.1, there's been basic
>> integration between HiveMind and Spring.
>>
>> At the core of it is the ability to define a HiveMind service in terms
>> of a Spring bean within a BeanFactory. The essential code is:
>>
>> public Object createCoreServiceImplementation(
>> ServiceImplementationFactoryParameters factoryParameters)
>> {
>> SpringBeanParameter p = (SpringBeanParameter)
>> factoryParameters.getFirstParameter();
>> String beanName = p.getName();
>>
>> BeanFactory f = p.getBeanFactory();
>>
>> if (f == null)
>> f = _defaultBeanFactory;
>>
>> return f.getBean(beanName, factoryParameters.getServiceInterface());
>> }
>>
>> With this, its possible to obtain a Spring bean and the core service
>> implementation of a HiveMind service. The implementation can be
>> extended with interceptors and injected into other HiveMind services.
>>
>> At Javapolis, I talked with Rod about having something similar going
>> the other direction, allowing HiveMind services to be referencable
>> (and injectable) as Spring beans. I'd like to provoke a discussion on
>> what that would look like, and what API changes would be needed in
>> HiveMind 1.1 to support it.
>>
>> Rod seemed to think (and I didn't follow the reasoning) that HiveMind
>> would need an API to iterate over the names of all services.
>>
>> In addition, configuration data (in either List or Map form) is also
>> quite valuable and something that Spring beans would like to have
>> access to.
>>
>> --
>> Howard M. Lewis Ship
>> Independent J2EE / Open-Source Java Consultant
>> Creator, Jakarta Tapestry
>> Creator, Jakarta HiveMind
>>
>> Professional Tapestry training, mentoring, support
>> and project work. http://howardlewisship.com
>>
>>
>> -------------------------------------------------------
>> This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
>> Tool for open source databases. Create drag-&-drop reports. Save time
>> by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
>> Download a FREE copy at http://www.intelliview.com/go/osdn_nl
>> _______________________________________________
>> Springframework-developer mailing list
>> Spr...@li...
>> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>>
>>
>>
>>
>>
>
>
>
>
|
|
From: Colin S. <col...@ex...> - 2005-01-29 13:20:17
|
I'm not sure it really matters, but given that Hivemind already has
Spring integration code, and we are talking about Hivemind integration
code for Spring, nobody has mentioned that we're going to end up with a
circular dependency here... There are some potential versioning issues,
but I guess they are a concern if you want to call from Spring to
Hivemind back to Spring, or Hivemind to Spring back to Hivemind...
Rob Harrop wrote:
> Howard,
>
> I think it will be quite simple to integrate HiveMind services into
> Spring. As I see it we need a HiveMindRegistryFactoryBean to create
> the Registry instance and then a HiveMindServiceFactoryBean that uses
> the Registry to lookup a given service. By default the
> HiveMindServiceFactoryBean would use the Spring bean name to lookup a
> service in the Registry, but users could configure a different service
> name using DI. With this mechanism, users can create one instance of
> Registry within a Spring application and then access many services
> from that Registry.
>
> If I have time today, I'll work on this. If not, I'll work on it next
> week some time.
>
> Rob
>
> Howard Lewis Ship wrote:
>
>> This comes up quite a bit, they are similiar in intent but quite
>> different in execution.
>>
>> - HiveMind has a very sophisiticated configurations model (very
>> similar to Eclipse plugins) based on configuration points and
>> contributions (from multiple locations)
>> - HiveMind is the infrastructure for Tapestry 3.1, and many Tapestry
>> applications also use Spring
>> - Because Rod and I (and the other Spring team member's I've talked
>> to) want to foster cooperation and compatability rather than
>> competition
>>
>>
>> On Fri, 28 Jan 2005 10:47:48 +1100, Mason, Ross
>> <ros...@vi...> wrote:
>>
>>
>>> Hi Howard,
>>>
>>> What is the use case for integrating HiveMind and Spring? I must
>>> admit I haven't had a chance to get a good look at HiveMind, but my
>>> understanding is that it is a DI container that provides service
>>> wiring and interception, much in the same vein as the Spring
>>> Container. From the outset the two containers seem to be mutally
>>> exclusive rather than complimentary.
>>>
>>> Can you shed some light on this for me?
>>>
>>> Cheers,
>>>
>>> Ross
>>>
>>> -----Original Message-----
>>> From: spr...@li...
>>> on behalf of Howard Lewis Ship
>>> Sent: Wed 26/01/2005 2:46 PM
>>> To: spr...@li...
>>> Cc:
>>> Subject: [Springframework-developer] Spring / HiveMind
>>> Integration
>>>
>>> Since HiveMind 1.0, and improved in HiveMind 1.1, there's
>>> been basic
>>> integration between HiveMind and Spring.
>>>
>>> At the core of it is the ability to define a HiveMind service
>>> in terms
>>> of a Spring bean within a BeanFactory. The essential code is:
>>>
>>> public Object createCoreServiceImplementation(
>>> ServiceImplementationFactoryParameters
>>> factoryParameters)
>>> {
>>> SpringBeanParameter p = (SpringBeanParameter)
>>> factoryParameters.getFirstParameter();
>>> String beanName = p.getName();
>>>
>>> BeanFactory f = p.getBeanFactory();
>>>
>>> if (f == null)
>>> f = _defaultBeanFactory;
>>>
>>> return f.getBean(beanName,
>>> factoryParameters.getServiceInterface());
>>> }
>>>
>>> With this, its possible to obtain a Spring bean and the core
>>> service
>>> implementation of a HiveMind service. The implementation can be
>>> extended with interceptors and injected into other HiveMind
>>> services.
>>>
>>> At Javapolis, I talked with Rod about having something
>>> similar going
>>> the other direction, allowing HiveMind services to be
>>> referencable
>>> (and injectable) as Spring beans. I'd like to provoke a
>>> discussion on
>>> what that would look like, and what API changes would be
>>> needed in
>>> HiveMind 1.1 to support it.
>>>
>>> Rod seemed to think (and I didn't follow the reasoning) that
>>> HiveMind
>>> would need an API to iterate over the names of all services.
>>>
>>> In addition, configuration data (in either List or Map form)
>>> is also
>>> quite valuable and something that Spring beans would like to
>>> have
>>> access to.
>>>
>>> --
>>> Howard M. Lewis Ship
>>> Independent J2EE / Open-Source Java Consultant
>>> Creator, Jakarta Tapestry
>>> Creator, Jakarta HiveMind
>>>
>>> Professional Tapestry training, mentoring, support
>>> and project work. http://howardlewisship.com
>>
|
|
From: Rob H. <ro...@ca...> - 2005-01-29 13:55:49
|
That is a concern, and I guess we could put in hooks to prevent this -
but I think it is probably simpler to say "Don't do this!".
Rob
Colin Sampaleanu wrote:
> I'm not sure it really matters, but given that Hivemind already has
> Spring integration code, and we are talking about Hivemind
> integration code for Spring, nobody has mentioned that we're going to
> end up with a circular dependency here... There are some potential
> versioning issues, but I guess they are a concern if you want to call
> from Spring to Hivemind back to Spring, or Hivemind to Spring back to
> Hivemind...
>
> Rob Harrop wrote:
>
>> Howard,
>>
>> I think it will be quite simple to integrate HiveMind services into
>> Spring. As I see it we need a HiveMindRegistryFactoryBean to create
>> the Registry instance and then a HiveMindServiceFactoryBean that uses
>> the Registry to lookup a given service. By default the
>> HiveMindServiceFactoryBean would use the Spring bean name to lookup a
>> service in the Registry, but users could configure a different
>> service name using DI. With this mechanism, users can create one
>> instance of Registry within a Spring application and then access many
>> services from that Registry.
>>
>> If I have time today, I'll work on this. If not, I'll work on it next
>> week some time.
>>
>> Rob
>>
>> Howard Lewis Ship wrote:
>>
>>> This comes up quite a bit, they are similiar in intent but quite
>>> different in execution.
>>>
>>> - HiveMind has a very sophisiticated configurations model (very
>>> similar to Eclipse plugins) based on configuration points and
>>> contributions (from multiple locations)
>>> - HiveMind is the infrastructure for Tapestry 3.1, and many Tapestry
>>> applications also use Spring
>>> - Because Rod and I (and the other Spring team member's I've talked
>>> to) want to foster cooperation and compatability rather than
>>> competition
>>>
>>>
>>> On Fri, 28 Jan 2005 10:47:48 +1100, Mason, Ross
>>> <ros...@vi...> wrote:
>>>
>>>
>>>> Hi Howard,
>>>>
>>>> What is the use case for integrating HiveMind and Spring? I must
>>>> admit I haven't had a chance to get a good look at HiveMind, but my
>>>> understanding is that it is a DI container that provides service
>>>> wiring and interception, much in the same vein as the Spring
>>>> Container. From the outset the two containers seem to be mutally
>>>> exclusive rather than complimentary.
>>>>
>>>> Can you shed some light on this for me?
>>>>
>>>> Cheers,
>>>>
>>>> Ross
>>>>
>>>> -----Original Message-----
>>>> From: spr...@li...
>>>> on behalf of Howard Lewis Ship
>>>> Sent: Wed 26/01/2005 2:46 PM
>>>> To: spr...@li...
>>>> Cc:
>>>> Subject: [Springframework-developer] Spring / HiveMind
>>>> Integration
>>>>
>>>> Since HiveMind 1.0, and improved in HiveMind 1.1, there's
>>>> been basic
>>>> integration between HiveMind and Spring.
>>>>
>>>> At the core of it is the ability to define a HiveMind
>>>> service in terms
>>>> of a Spring bean within a BeanFactory. The essential code is:
>>>>
>>>> public Object createCoreServiceImplementation(
>>>> ServiceImplementationFactoryParameters
>>>> factoryParameters)
>>>> {
>>>> SpringBeanParameter p = (SpringBeanParameter)
>>>> factoryParameters.getFirstParameter();
>>>> String beanName = p.getName();
>>>>
>>>> BeanFactory f = p.getBeanFactory();
>>>>
>>>> if (f == null)
>>>> f = _defaultBeanFactory;
>>>>
>>>> return f.getBean(beanName,
>>>> factoryParameters.getServiceInterface());
>>>> }
>>>>
>>>> With this, its possible to obtain a Spring bean and the core
>>>> service
>>>> implementation of a HiveMind service. The implementation
>>>> can be
>>>> extended with interceptors and injected into other HiveMind
>>>> services.
>>>>
>>>> At Javapolis, I talked with Rod about having something
>>>> similar going
>>>> the other direction, allowing HiveMind services to be
>>>> referencable
>>>> (and injectable) as Spring beans. I'd like to provoke a
>>>> discussion on
>>>> what that would look like, and what API changes would be
>>>> needed in
>>>> HiveMind 1.1 to support it.
>>>>
>>>> Rod seemed to think (and I didn't follow the reasoning) that
>>>> HiveMind
>>>> would need an API to iterate over the names of all services.
>>>>
>>>> In addition, configuration data (in either List or Map form)
>>>> is also
>>>> quite valuable and something that Spring beans would like to
>>>> have
>>>> access to.
>>>>
>>>> --
>>>> Howard M. Lewis Ship
>>>> Independent J2EE / Open-Source Java Consultant
>>>> Creator, Jakarta Tapestry
>>>> Creator, Jakarta HiveMind
>>>>
>>>> Professional Tapestry training, mentoring, support
>>>> and project work. http://howardlewisship.com
>>>
>>>
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
> Tool for open source databases. Create drag-&-drop reports. Save time
> by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
> Download a FREE copy at http://www.intelliview.com/go/osdn_nl
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
|
|
From: Juergen H. <ju...@in...> - 2005-01-29 14:14:46
|
I guess the problem is also about shipping. If HiveMind ships with Spring,
and Spring would then ship with HiveMind too, it seems to me that we could
simplify this: Why not put all Spring/HiveMind integration code into
HiveMind Extras or a Spring-HiveMind project or the like? There would a
single place to maintain both ways of integration then, for specific
versions of Spring and HiveMind.
Even if we included HiveMind integration in Spring, we would have to do this
in a separate distribution, Spring Extras or whatever it would be called. It
is certainly not feasible to extend the dependencies of the core Spring
distribution to integration with other lightweight containers, given that we
already ship all sorts of persistence and web view libraries etc.
Juergen
-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of Rob Harrop
Sent: Saturday, January 29, 2005 2:54 PM
To: spr...@li...
Subject: Re: [Springframework-developer] Spring / HiveMind Integration
That is a concern, and I guess we could put in hooks to prevent this -
but I think it is probably simpler to say "Don't do this!".
Rob
Colin Sampaleanu wrote:
> I'm not sure it really matters, but given that Hivemind already has
> Spring integration code, and we are talking about Hivemind
> integration code for Spring, nobody has mentioned that we're going to
> end up with a circular dependency here... There are some potential
> versioning issues, but I guess they are a concern if you want to call
> from Spring to Hivemind back to Spring, or Hivemind to Spring back to
> Hivemind...
>
> Rob Harrop wrote:
>
>> Howard,
>>
>> I think it will be quite simple to integrate HiveMind services into
>> Spring. As I see it we need a HiveMindRegistryFactoryBean to create
>> the Registry instance and then a HiveMindServiceFactoryBean that uses
>> the Registry to lookup a given service. By default the
>> HiveMindServiceFactoryBean would use the Spring bean name to lookup a
>> service in the Registry, but users could configure a different
>> service name using DI. With this mechanism, users can create one
>> instance of Registry within a Spring application and then access many
>> services from that Registry.
>>
>> If I have time today, I'll work on this. If not, I'll work on it next
>> week some time.
>>
>> Rob
>>
>> Howard Lewis Ship wrote:
>>
>>> This comes up quite a bit, they are similiar in intent but quite
>>> different in execution.
>>>
>>> - HiveMind has a very sophisiticated configurations model (very
>>> similar to Eclipse plugins) based on configuration points and
>>> contributions (from multiple locations)
>>> - HiveMind is the infrastructure for Tapestry 3.1, and many Tapestry
>>> applications also use Spring
>>> - Because Rod and I (and the other Spring team member's I've talked
>>> to) want to foster cooperation and compatability rather than
>>> competition
>>>
>>>
>>> On Fri, 28 Jan 2005 10:47:48 +1100, Mason, Ross
>>> <ros...@vi...> wrote:
>>>
>>>
>>>> Hi Howard,
>>>>
>>>> What is the use case for integrating HiveMind and Spring? I must
>>>> admit I haven't had a chance to get a good look at HiveMind, but my
>>>> understanding is that it is a DI container that provides service
>>>> wiring and interception, much in the same vein as the Spring
>>>> Container. From the outset the two containers seem to be mutally
>>>> exclusive rather than complimentary.
>>>>
>>>> Can you shed some light on this for me?
>>>>
>>>> Cheers,
>>>>
>>>> Ross
>>>>
>>>> -----Original Message-----
>>>> From: spr...@li...
>>>> on behalf of Howard Lewis Ship
>>>> Sent: Wed 26/01/2005 2:46 PM
>>>> To: spr...@li...
>>>> Cc:
>>>> Subject: [Springframework-developer] Spring / HiveMind
>>>> Integration
>>>>
>>>> Since HiveMind 1.0, and improved in HiveMind 1.1, there's
>>>> been basic
>>>> integration between HiveMind and Spring.
>>>>
>>>> At the core of it is the ability to define a HiveMind
>>>> service in terms
>>>> of a Spring bean within a BeanFactory. The essential code is:
>>>>
>>>> public Object createCoreServiceImplementation(
>>>> ServiceImplementationFactoryParameters
>>>> factoryParameters)
>>>> {
>>>> SpringBeanParameter p = (SpringBeanParameter)
>>>> factoryParameters.getFirstParameter();
>>>> String beanName = p.getName();
>>>>
>>>> BeanFactory f = p.getBeanFactory();
>>>>
>>>> if (f == null)
>>>> f = _defaultBeanFactory;
>>>>
>>>> return f.getBean(beanName,
>>>> factoryParameters.getServiceInterface());
>>>> }
>>>>
>>>> With this, its possible to obtain a Spring bean and the core
>>>> service
>>>> implementation of a HiveMind service. The implementation
>>>> can be
>>>> extended with interceptors and injected into other HiveMind
>>>> services.
>>>>
>>>> At Javapolis, I talked with Rod about having something
>>>> similar going
>>>> the other direction, allowing HiveMind services to be
>>>> referencable
>>>> (and injectable) as Spring beans. I'd like to provoke a
>>>> discussion on
>>>> what that would look like, and what API changes would be
>>>> needed in
>>>> HiveMind 1.1 to support it.
>>>>
>>>> Rod seemed to think (and I didn't follow the reasoning) that
>>>> HiveMind
>>>> would need an API to iterate over the names of all services.
>>>>
>>>> In addition, configuration data (in either List or Map form)
>>>> is also
>>>> quite valuable and something that Spring beans would like to
>>>> have
>>>> access to.
>>>>
>>>> --
>>>> Howard M. Lewis Ship
>>>> Independent J2EE / Open-Source Java Consultant
>>>> Creator, Jakarta Tapestry
>>>> Creator, Jakarta HiveMind
>>>>
>>>> Professional Tapestry training, mentoring, support
>>>> and project work. http://howardlewisship.com
>>>
>>>
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
> Tool for open source databases. Create drag-&-drop reports. Save time
> by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
> Download a FREE copy at http://www.intelliview.com/go/osdn_nl
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer
|
|
From: Rob H. <ro...@ca...> - 2005-01-29 14:28:38
|
I was thinking of distributing this as one of the first things in the a
separate project containing extensions and add-ons to Spring. I've been
working on a couple of other modules as well which I think should be
kept separate from the core.
Rob
Juergen Hoeller wrote:
>I guess the problem is also about shipping. If HiveMind ships with Spring,
>and Spring would then ship with HiveMind too, it seems to me that we could
>simplify this: Why not put all Spring/HiveMind integration code into
>HiveMind Extras or a Spring-HiveMind project or the like? There would a
>single place to maintain both ways of integration then, for specific
>versions of Spring and HiveMind.
>
>Even if we included HiveMind integration in Spring, we would have to do this
>in a separate distribution, Spring Extras or whatever it would be called. It
>is certainly not feasible to extend the dependencies of the core Spring
>distribution to integration with other lightweight containers, given that we
>already ship all sorts of persistence and web view libraries etc.
>
>Juergen
>
>
>-----Original Message-----
>From: spr...@li...
>[mailto:spr...@li...]On Behalf
>Of Rob Harrop
>Sent: Saturday, January 29, 2005 2:54 PM
>To: spr...@li...
>Subject: Re: [Springframework-developer] Spring / HiveMind Integration
>
>
>That is a concern, and I guess we could put in hooks to prevent this -
>but I think it is probably simpler to say "Don't do this!".
>
>Rob
>
>Colin Sampaleanu wrote:
>
>
>
>>I'm not sure it really matters, but given that Hivemind already has
>>Spring integration code, and we are talking about Hivemind
>>integration code for Spring, nobody has mentioned that we're going to
>>end up with a circular dependency here... There are some potential
>>versioning issues, but I guess they are a concern if you want to call
>>from Spring to Hivemind back to Spring, or Hivemind to Spring back to
>>Hivemind...
>>
>>Rob Harrop wrote:
>>
>>
>>
>>>Howard,
>>>
>>>I think it will be quite simple to integrate HiveMind services into
>>>Spring. As I see it we need a HiveMindRegistryFactoryBean to create
>>>the Registry instance and then a HiveMindServiceFactoryBean that uses
>>>the Registry to lookup a given service. By default the
>>>HiveMindServiceFactoryBean would use the Spring bean name to lookup a
>>>service in the Registry, but users could configure a different
>>>service name using DI. With this mechanism, users can create one
>>>instance of Registry within a Spring application and then access many
>>>services from that Registry.
>>>
>>>If I have time today, I'll work on this. If not, I'll work on it next
>>>week some time.
>>>
>>>Rob
>>>
>>>Howard Lewis Ship wrote:
>>>
>>>
>>>
>>>>This comes up quite a bit, they are similiar in intent but quite
>>>>different in execution.
>>>>
>>>>- HiveMind has a very sophisiticated configurations model (very
>>>>similar to Eclipse plugins) based on configuration points and
>>>>contributions (from multiple locations)
>>>>- HiveMind is the infrastructure for Tapestry 3.1, and many Tapestry
>>>>applications also use Spring
>>>>- Because Rod and I (and the other Spring team member's I've talked
>>>>to) want to foster cooperation and compatability rather than
>>>>competition
>>>>
>>>>
>>>>On Fri, 28 Jan 2005 10:47:48 +1100, Mason, Ross
>>>><ros...@vi...> wrote:
>>>>
>>>>
>>>>
>>>>
>>>>>Hi Howard,
>>>>>
>>>>>What is the use case for integrating HiveMind and Spring? I must
>>>>>admit I haven't had a chance to get a good look at HiveMind, but my
>>>>>understanding is that it is a DI container that provides service
>>>>>wiring and interception, much in the same vein as the Spring
>>>>>Container. From the outset the two containers seem to be mutally
>>>>>exclusive rather than complimentary.
>>>>>
>>>>>Can you shed some light on this for me?
>>>>>
>>>>>Cheers,
>>>>>
>>>>>Ross
>>>>>
>>>>> -----Original Message-----
>>>>> From: spr...@li...
>>>>>on behalf of Howard Lewis Ship
>>>>> Sent: Wed 26/01/2005 2:46 PM
>>>>> To: spr...@li...
>>>>> Cc:
>>>>> Subject: [Springframework-developer] Spring / HiveMind
>>>>>Integration
>>>>>
>>>>> Since HiveMind 1.0, and improved in HiveMind 1.1, there's
>>>>>been basic
>>>>> integration between HiveMind and Spring.
>>>>>
>>>>> At the core of it is the ability to define a HiveMind
>>>>>service in terms
>>>>> of a Spring bean within a BeanFactory. The essential code is:
>>>>>
>>>>> public Object createCoreServiceImplementation(
>>>>> ServiceImplementationFactoryParameters
>>>>>factoryParameters)
>>>>> {
>>>>> SpringBeanParameter p = (SpringBeanParameter)
>>>>> factoryParameters.getFirstParameter();
>>>>> String beanName = p.getName();
>>>>>
>>>>> BeanFactory f = p.getBeanFactory();
>>>>>
>>>>> if (f == null)
>>>>> f = _defaultBeanFactory;
>>>>>
>>>>> return f.getBean(beanName,
>>>>>factoryParameters.getServiceInterface());
>>>>> }
>>>>>
>>>>> With this, its possible to obtain a Spring bean and the core
>>>>>service
>>>>> implementation of a HiveMind service. The implementation
>>>>>can be
>>>>> extended with interceptors and injected into other HiveMind
>>>>>services.
>>>>>
>>>>> At Javapolis, I talked with Rod about having something
>>>>>similar going
>>>>> the other direction, allowing HiveMind services to be
>>>>>referencable
>>>>> (and injectable) as Spring beans. I'd like to provoke a
>>>>>discussion on
>>>>> what that would look like, and what API changes would be
>>>>>needed in
>>>>> HiveMind 1.1 to support it.
>>>>>
>>>>> Rod seemed to think (and I didn't follow the reasoning) that
>>>>>HiveMind
>>>>> would need an API to iterate over the names of all services.
>>>>>
>>>>> In addition, configuration data (in either List or Map form)
>>>>>is also
>>>>> quite valuable and something that Spring beans would like to
>>>>>have
>>>>> access to.
>>>>>
>>>>> --
>>>>> Howard M. Lewis Ship
>>>>> Independent J2EE / Open-Source Java Consultant
>>>>> Creator, Jakarta Tapestry
>>>>> Creator, Jakarta HiveMind
>>>>>
>>>>> Professional Tapestry training, mentoring, support
>>>>> and project work. http://howardlewisship.com
>>>>>
>>>>>
>>>>
>>>>
>>
>>-------------------------------------------------------
>>This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
>>Tool for open source databases. Create drag-&-drop reports. Save time
>>by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
>>Download a FREE copy at http://www.intelliview.com/go/osdn_nl
>>_______________________________________________
>>Springframework-developer mailing list
>>Spr...@li...
>>https://lists.sourceforge.net/lists/listinfo/springframework-developer
>>
>>
>>
>>
>
>
>-------------------------------------------------------
>This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
>Tool for open source databases. Create drag-&-drop reports. Save time
>by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
>Download a FREE copy at http://www.intelliview.com/go/osdn_nl
>_______________________________________________
>Springframework-developer mailing list
>Spr...@li...
>https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>
>-------------------------------------------------------
>This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
>Tool for open source databases. Create drag-&-drop reports. Save time
>by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
>Download a FREE copy at http://www.intelliview.com/go/osdn_nl
>_______________________________________________
>Springframework-developer mailing list
>Spr...@li...
>https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>
>
|
|
From: Juergen H. <ju...@in...> - 2005-01-29 14:31:27
|
I was mainly wondering whether it makes sense to separate HiveMind/Spring
integration and Spring/HiveMind integration... Shouldn't we put both into
the *same* distribution?
Juergen
-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of Rob Harrop
Sent: Saturday, January 29, 2005 3:27 PM
To: spr...@li...
Subject: Re: [Springframework-developer] Spring / HiveMind Integration
I was thinking of distributing this as one of the first things in the a
separate project containing extensions and add-ons to Spring. I've been
working on a couple of other modules as well which I think should be
kept separate from the core.
Rob
Juergen Hoeller wrote:
>I guess the problem is also about shipping. If HiveMind ships with Spring,
>and Spring would then ship with HiveMind too, it seems to me that we could
>simplify this: Why not put all Spring/HiveMind integration code into
>HiveMind Extras or a Spring-HiveMind project or the like? There would a
>single place to maintain both ways of integration then, for specific
>versions of Spring and HiveMind.
>
>Even if we included HiveMind integration in Spring, we would have to do
this
>in a separate distribution, Spring Extras or whatever it would be called.
It
>is certainly not feasible to extend the dependencies of the core Spring
>distribution to integration with other lightweight containers, given that
we
>already ship all sorts of persistence and web view libraries etc.
>
>Juergen
>
>
>-----Original Message-----
>From: spr...@li...
>[mailto:spr...@li...]On Behalf
>Of Rob Harrop
>Sent: Saturday, January 29, 2005 2:54 PM
>To: spr...@li...
>Subject: Re: [Springframework-developer] Spring / HiveMind Integration
>
>
>That is a concern, and I guess we could put in hooks to prevent this -
>but I think it is probably simpler to say "Don't do this!".
>
>Rob
>
>Colin Sampaleanu wrote:
>
>
>
>>I'm not sure it really matters, but given that Hivemind already has
>>Spring integration code, and we are talking about Hivemind
>>integration code for Spring, nobody has mentioned that we're going to
>>end up with a circular dependency here... There are some potential
>>versioning issues, but I guess they are a concern if you want to call
>>from Spring to Hivemind back to Spring, or Hivemind to Spring back to
>>Hivemind...
>>
>>Rob Harrop wrote:
>>
>>
>>
>>>Howard,
>>>
>>>I think it will be quite simple to integrate HiveMind services into
>>>Spring. As I see it we need a HiveMindRegistryFactoryBean to create
>>>the Registry instance and then a HiveMindServiceFactoryBean that uses
>>>the Registry to lookup a given service. By default the
>>>HiveMindServiceFactoryBean would use the Spring bean name to lookup a
>>>service in the Registry, but users could configure a different
>>>service name using DI. With this mechanism, users can create one
>>>instance of Registry within a Spring application and then access many
>>>services from that Registry.
>>>
>>>If I have time today, I'll work on this. If not, I'll work on it next
>>>week some time.
>>>
>>>Rob
>>>
>>>Howard Lewis Ship wrote:
>>>
>>>
>>>
>>>>This comes up quite a bit, they are similiar in intent but quite
>>>>different in execution.
>>>>
>>>>- HiveMind has a very sophisiticated configurations model (very
>>>>similar to Eclipse plugins) based on configuration points and
>>>>contributions (from multiple locations)
>>>>- HiveMind is the infrastructure for Tapestry 3.1, and many Tapestry
>>>>applications also use Spring
>>>>- Because Rod and I (and the other Spring team member's I've talked
>>>>to) want to foster cooperation and compatability rather than
>>>>competition
>>>>
>>>>
>>>>On Fri, 28 Jan 2005 10:47:48 +1100, Mason, Ross
>>>><ros...@vi...> wrote:
>>>>
>>>>
>>>>
>>>>
>>>>>Hi Howard,
>>>>>
>>>>>What is the use case for integrating HiveMind and Spring? I must
>>>>>admit I haven't had a chance to get a good look at HiveMind, but my
>>>>>understanding is that it is a DI container that provides service
>>>>>wiring and interception, much in the same vein as the Spring
>>>>>Container. From the outset the two containers seem to be mutally
>>>>>exclusive rather than complimentary.
>>>>>
>>>>>Can you shed some light on this for me?
>>>>>
>>>>>Cheers,
>>>>>
>>>>>Ross
>>>>>
>>>>> -----Original Message-----
>>>>> From: spr...@li...
>>>>>on behalf of Howard Lewis Ship
>>>>> Sent: Wed 26/01/2005 2:46 PM
>>>>> To: spr...@li...
>>>>> Cc:
>>>>> Subject: [Springframework-developer] Spring / HiveMind
>>>>>Integration
>>>>>
>>>>> Since HiveMind 1.0, and improved in HiveMind 1.1, there's
>>>>>been basic
>>>>> integration between HiveMind and Spring.
>>>>>
>>>>> At the core of it is the ability to define a HiveMind
>>>>>service in terms
>>>>> of a Spring bean within a BeanFactory. The essential code is:
>>>>>
>>>>> public Object createCoreServiceImplementation(
>>>>> ServiceImplementationFactoryParameters
>>>>>factoryParameters)
>>>>> {
>>>>> SpringBeanParameter p = (SpringBeanParameter)
>>>>> factoryParameters.getFirstParameter();
>>>>> String beanName = p.getName();
>>>>>
>>>>> BeanFactory f = p.getBeanFactory();
>>>>>
>>>>> if (f == null)
>>>>> f = _defaultBeanFactory;
>>>>>
>>>>> return f.getBean(beanName,
>>>>>factoryParameters.getServiceInterface());
>>>>> }
>>>>>
>>>>> With this, its possible to obtain a Spring bean and the core
>>>>>service
>>>>> implementation of a HiveMind service. The implementation
>>>>>can be
>>>>> extended with interceptors and injected into other HiveMind
>>>>>services.
>>>>>
>>>>> At Javapolis, I talked with Rod about having something
>>>>>similar going
>>>>> the other direction, allowing HiveMind services to be
>>>>>referencable
>>>>> (and injectable) as Spring beans. I'd like to provoke a
>>>>>discussion on
>>>>> what that would look like, and what API changes would be
>>>>>needed in
>>>>> HiveMind 1.1 to support it.
>>>>>
>>>>> Rod seemed to think (and I didn't follow the reasoning) that
>>>>>HiveMind
>>>>> would need an API to iterate over the names of all services.
>>>>>
>>>>> In addition, configuration data (in either List or Map form)
>>>>>is also
>>>>> quite valuable and something that Spring beans would like to
>>>>>have
>>>>> access to.
>>>>>
>>>>> --
>>>>> Howard M. Lewis Ship
>>>>> Independent J2EE / Open-Source Java Consultant
>>>>> Creator, Jakarta Tapestry
>>>>> Creator, Jakarta HiveMind
>>>>>
>>>>> Professional Tapestry training, mentoring, support
>>>>> and project work. http://howardlewisship.com
>>>>>
>>>>>
>>>>
>>>>
>>
>>-------------------------------------------------------
>>This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
>>Tool for open source databases. Create drag-&-drop reports. Save time
>>by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
>>Download a FREE copy at http://www.intelliview.com/go/osdn_nl
>>_______________________________________________
>>Springframework-developer mailing list
>>Spr...@li...
>>https://lists.sourceforge.net/lists/listinfo/springframework-developer
>>
>>
>>
>>
>
>
>-------------------------------------------------------
>This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
>Tool for open source databases. Create drag-&-drop reports. Save time
>by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
>Download a FREE copy at http://www.intelliview.com/go/osdn_nl
>_______________________________________________
>Springframework-developer mailing list
>Spr...@li...
>https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>
>-------------------------------------------------------
>This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
>Tool for open source databases. Create drag-&-drop reports. Save time
>by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
>Download a FREE copy at http://www.intelliview.com/go/osdn_nl
>_______________________________________________
>Springframework-developer mailing list
>Spr...@li...
>https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>
>
-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer
|
|
From: Colin S. <col...@ex...> - 2005-01-29 15:14:06
|
Yes, I have to agree this probably makes sense... It's a little less
convenient, but resolves versioning issues. One question is whether you
can do a good enough integration that way, but I would that would not be
an issue, it's not like you want to make one container dependent on the
other anyway at it's core, so any integration should be at a higher level.
Juergen Hoeller wrote:
>I was mainly wondering whether it makes sense to separate HiveMind/Spring
>integration and Spring/HiveMind integration... Shouldn't we put both into
>the *same* distribution?
>
>Juergen
>
>
>-----Original Message-----
>From: spr...@li...
>[mailto:spr...@li...]On Behalf
>Of Rob Harrop
>Sent: Saturday, January 29, 2005 3:27 PM
>To: spr...@li...
>Subject: Re: [Springframework-developer] Spring / HiveMind Integration
>
>
>I was thinking of distributing this as one of the first things in the a
>separate project containing extensions and add-ons to Spring. I've been
>working on a couple of other modules as well which I think should be
>kept separate from the core.
>
>Rob
>
>Juergen Hoeller wrote:
>
>
>
>>I guess the problem is also about shipping. If HiveMind ships with Spring,
>>and Spring would then ship with HiveMind too, it seems to me that we could
>>simplify this: Why not put all Spring/HiveMind integration code into
>>HiveMind Extras or a Spring-HiveMind project or the like? There would a
>>single place to maintain both ways of integration then, for specific
>>versions of Spring and HiveMind.
>>
>>Even if we included HiveMind integration in Spring, we would have to do
>>
>>
>this
>
>
>>in a separate distribution, Spring Extras or whatever it would be called.
>>
>>
>It
>
>
>>is certainly not feasible to extend the dependencies of the core Spring
>>distribution to integration with other lightweight containers, given that
>>
>>
>we
>
>
>>already ship all sorts of persistence and web view libraries etc.
>>
>>Juergen
>>
>>
>>-----Original Message-----
>>From: spr...@li...
>>[mailto:spr...@li...]On Behalf
>>Of Rob Harrop
>>Sent: Saturday, January 29, 2005 2:54 PM
>>To: spr...@li...
>>Subject: Re: [Springframework-developer] Spring / HiveMind Integration
>>
>>
>>That is a concern, and I guess we could put in hooks to prevent this -
>>but I think it is probably simpler to say "Don't do this!".
>>
>>Rob
>>
>>Colin Sampaleanu wrote:
>>
>>
>>
>>
>>
>>>I'm not sure it really matters, but given that Hivemind already has
>>>Spring integration code, and we are talking about Hivemind
>>>integration code for Spring, nobody has mentioned that we're going to
>>>end up with a circular dependency here... There are some potential
>>>versioning issues, but I guess they are a concern if you want to call
>>>
>>>
>>>from Spring to Hivemind back to Spring, or Hivemind to Spring back to
>>
>>
>>>Hivemind...
>>>
>>>Rob Harrop wrote:
>>>
>>>
>>>
>>>
>>>
>>>>Howard,
>>>>
>>>>I think it will be quite simple to integrate HiveMind services into
>>>>Spring. As I see it we need a HiveMindRegistryFactoryBean to create
>>>>the Registry instance and then a HiveMindServiceFactoryBean that uses
>>>>the Registry to lookup a given service. By default the
>>>>HiveMindServiceFactoryBean would use the Spring bean name to lookup a
>>>>service in the Registry, but users could configure a different
>>>>service name using DI. With this mechanism, users can create one
>>>>instance of Registry within a Spring application and then access many
>>>>services from that Registry.
>>>>
>>>>If I have time today, I'll work on this. If not, I'll work on it next
>>>>week some time.
>>>>
>>>>Rob
>>>>
>>>>Howard Lewis Ship wrote:
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>>This comes up quite a bit, they are similiar in intent but quite
>>>>>different in execution.
>>>>>
>>>>>- HiveMind has a very sophisiticated configurations model (very
>>>>>similar to Eclipse plugins) based on configuration points and
>>>>>contributions (from multiple locations)
>>>>>- HiveMind is the infrastructure for Tapestry 3.1, and many Tapestry
>>>>>applications also use Spring
>>>>>- Because Rod and I (and the other Spring team member's I've talked
>>>>>to) want to foster cooperation and compatability rather than
>>>>>competition
>>>>>
>>>>>
>>>>>On Fri, 28 Jan 2005 10:47:48 +1100, Mason, Ross
>>>>><ros...@vi...> wrote:
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>Hi Howard,
>>>>>>
>>>>>>What is the use case for integrating HiveMind and Spring? I must
>>>>>>admit I haven't had a chance to get a good look at HiveMind, but my
>>>>>>understanding is that it is a DI container that provides service
>>>>>>wiring and interception, much in the same vein as the Spring
>>>>>>Container. From the outset the two containers seem to be mutally
>>>>>>exclusive rather than complimentary.
>>>>>>
>>>>>>Can you shed some light on this for me?
>>>>>>
>>>>>>Cheers,
>>>>>>
>>>>>>Ross
>>>>>>
>>>>>> -----Original Message-----
>>>>>> From: spr...@li...
>>>>>>on behalf of Howard Lewis Ship
>>>>>> Sent: Wed 26/01/2005 2:46 PM
>>>>>> To: spr...@li...
>>>>>> Cc:
>>>>>> Subject: [Springframework-developer] Spring / HiveMind
>>>>>>Integration
>>>>>>
>>>>>> Since HiveMind 1.0, and improved in HiveMind 1.1, there's
>>>>>>been basic
>>>>>> integration between HiveMind and Spring.
>>>>>>
>>>>>> At the core of it is the ability to define a HiveMind
>>>>>>service in terms
>>>>>> of a Spring bean within a BeanFactory. The essential code is:
>>>>>>
>>>>>> public Object createCoreServiceImplementation(
>>>>>> ServiceImplementationFactoryParameters
>>>>>>factoryParameters)
>>>>>> {
>>>>>> SpringBeanParameter p = (SpringBeanParameter)
>>>>>> factoryParameters.getFirstParameter();
>>>>>> String beanName = p.getName();
>>>>>>
>>>>>> BeanFactory f = p.getBeanFactory();
>>>>>>
>>>>>> if (f == null)
>>>>>> f = _defaultBeanFactory;
>>>>>>
>>>>>> return f.getBean(beanName,
>>>>>>factoryParameters.getServiceInterface());
>>>>>> }
>>>>>>
>>>>>> With this, its possible to obtain a Spring bean and the core
>>>>>>service
>>>>>> implementation of a HiveMind service. The implementation
>>>>>>can be
>>>>>> extended with interceptors and injected into other HiveMind
>>>>>>services.
>>>>>>
>>>>>> At Javapolis, I talked with Rod about having something
>>>>>>similar going
>>>>>> the other direction, allowing HiveMind services to be
>>>>>>referencable
>>>>>> (and injectable) as Spring beans. I'd like to provoke a
>>>>>>discussion on
>>>>>> what that would look like, and what API changes would be
>>>>>>needed in
>>>>>> HiveMind 1.1 to support it.
>>>>>>
>>>>>> Rod seemed to think (and I didn't follow the reasoning) that
>>>>>>HiveMind
>>>>>> would need an API to iterate over the names of all services.
>>>>>>
>>>>>> In addition, configuration data (in either List or Map form)
>>>>>>is also
>>>>>> quite valuable and something that Spring beans would like to
>>>>>>have
>>>>>> access to.
>>>>>>
>>>>>> --
>>>>>> Howard M. Lewis Ship
>>>>>> Independent J2EE / Open-Source Java Consultant
>>>>>> Creator, Jakarta Tapestry
>>>>>> Creator, Jakarta HiveMind
>>>>>>
>>>>>> Professional Tapestry training, mentoring, support
>>>>>> and project work. http://howardlewisship.com
>>>>>>
>>>>>>
|
|
From: jbetancourt <jbe...@co...> - 2005-01-29 16:55:42
|
Why not just go a little further and provide a generic IoC interface? That
is, a way for any IoC Container (IoCC) to interact with another.
Though there are only a few IoCCs now, there may be more later, or there may
be things that are similar, like EJB3 stuff. As with hierarchical
containers, you sometimes don't care which level a bean comes from, you also
don't care which container is really providing a service. Thus, an
application could possibly mix container frameworks and target them where
they provide more value-add. Sounds unlikely I guess.
----- Original Message -----
From: "Colin Sampaleanu" <col...@ex...>
To: <spr...@li...>
Sent: Saturday, January 29, 2005 10:13 AM
Subject: Re: [Springframework-developer] Spring / HiveMind Integration
> Yes, I have to agree this probably makes sense... It's a little less
> convenient, but resolves versioning issues. One question is whether you
> can do a good enough integration that way, but I would that would not be
> an issue, it's not like you want to make one container dependent on the
> other anyway at it's core, so any integration should be at a higher level.
>
>
> Juergen Hoeller wrote:
>
> >I was mainly wondering whether it makes sense to separate HiveMind/Spring
> >integration and Spring/HiveMind integration... Shouldn't we put both into
> >the *same* distribution?
> >
> >Juergen
> >
> >
> >-----Original Message-----
> >From: spr...@li...
> >[mailto:spr...@li...]On Behalf
> >Of Rob Harrop
> >Sent: Saturday, January 29, 2005 3:27 PM
> >To: spr...@li...
> >Subject: Re: [Springframework-developer] Spring / HiveMind Integration
> >
> >
> >I was thinking of distributing this as one of the first things in the a
> >separate project containing extensions and add-ons to Spring. I've been
> >working on a couple of other modules as well which I think should be
> >kept separate from the core.
> >
> >Rob
> >
> >Juergen Hoeller wrote:
> >
> >
> >
> >>I guess the problem is also about shipping. If HiveMind ships with
Spring,
> >>and Spring would then ship with HiveMind too, it seems to me that we
could
> >>simplify this: Why not put all Spring/HiveMind integration code into
> >>HiveMind Extras or a Spring-HiveMind project or the like? There would a
> >>single place to maintain both ways of integration then, for specific
> >>versions of Spring and HiveMind.
> >>
> >>Even if we included HiveMind integration in Spring, we would have to do
> >>
> >>
> >this
> >
> >
> >>in a separate distribution, Spring Extras or whatever it would be
called.
> >>
> >>
> >It
> >
> >
> >>is certainly not feasible to extend the dependencies of the core Spring
> >>distribution to integration with other lightweight containers, given
that
> >>
> >>
> >we
> >
> >
> >>already ship all sorts of persistence and web view libraries etc.
> >>
> >>Juergen
> >>
> >>
> >>-----Original Message-----
> >>From: spr...@li...
> >>[mailto:spr...@li...]On Behalf
> >>Of Rob Harrop
> >>Sent: Saturday, January 29, 2005 2:54 PM
> >>To: spr...@li...
> >>Subject: Re: [Springframework-developer] Spring / HiveMind Integration
> >>
> >>
> >>That is a concern, and I guess we could put in hooks to prevent this -
> >>but I think it is probably simpler to say "Don't do this!".
> >>
> >>Rob
> >>
> >>Colin Sampaleanu wrote:
> >>
> >>
> >>
> >>
> >>
> >>>I'm not sure it really matters, but given that Hivemind already has
> >>>Spring integration code, and we are talking about Hivemind
> >>>integration code for Spring, nobody has mentioned that we're going to
> >>>end up with a circular dependency here... There are some potential
> >>>versioning issues, but I guess they are a concern if you want to call
> >>>
> >>>
> >>>from Spring to Hivemind back to Spring, or Hivemind to Spring back to
> >>
> >>
> >>>Hivemind...
> >>>
> >>>Rob Harrop wrote:
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>>Howard,
> >>>>
> >>>>I think it will be quite simple to integrate HiveMind services into
> >>>>Spring. As I see it we need a HiveMindRegistryFactoryBean to create
> >>>>the Registry instance and then a HiveMindServiceFactoryBean that uses
> >>>>the Registry to lookup a given service. By default the
> >>>>HiveMindServiceFactoryBean would use the Spring bean name to lookup a
> >>>>service in the Registry, but users could configure a different
> >>>>service name using DI. With this mechanism, users can create one
> >>>>instance of Registry within a Spring application and then access many
> >>>>services from that Registry.
> >>>>
> >>>>If I have time today, I'll work on this. If not, I'll work on it next
> >>>>week some time.
> >>>>
> >>>>Rob
> >>>>
> >>>>Howard Lewis Ship wrote:
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>>This comes up quite a bit, they are similiar in intent but quite
> >>>>>different in execution.
> >>>>>
> >>>>>- HiveMind has a very sophisiticated configurations model (very
> >>>>>similar to Eclipse plugins) based on configuration points and
> >>>>>contributions (from multiple locations)
> >>>>>- HiveMind is the infrastructure for Tapestry 3.1, and many Tapestry
> >>>>>applications also use Spring
> >>>>>- Because Rod and I (and the other Spring team member's I've talked
> >>>>>to) want to foster cooperation and compatability rather than
> >>>>>competition
> >>>>>
> >>>>>
> >>>>>On Fri, 28 Jan 2005 10:47:48 +1100, Mason, Ross
> >>>>><ros...@vi...> wrote:
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>>Hi Howard,
> >>>>>>
> >>>>>>What is the use case for integrating HiveMind and Spring? I must
> >>>>>>admit I haven't had a chance to get a good look at HiveMind, but my
> >>>>>>understanding is that it is a DI container that provides service
> >>>>>>wiring and interception, much in the same vein as the Spring
> >>>>>>Container. From the outset the two containers seem to be mutally
> >>>>>>exclusive rather than complimentary.
> >>>>>>
> >>>>>>Can you shed some light on this for me?
> >>>>>>
> >>>>>>Cheers,
> >>>>>>
> >>>>>>Ross
> >>>>>>
> >>>>>> -----Original Message-----
> >>>>>> From: spr...@li...
> >>>>>>on behalf of Howard Lewis Ship
> >>>>>> Sent: Wed 26/01/2005 2:46 PM
> >>>>>> To: spr...@li...
> >>>>>> Cc:
> >>>>>> Subject: [Springframework-developer] Spring / HiveMind
> >>>>>>Integration
> >>>>>>
> >>>>>> Since HiveMind 1.0, and improved in HiveMind 1.1, there's
> >>>>>>been basic
> >>>>>> integration between HiveMind and Spring.
> >>>>>>
> >>>>>> At the core of it is the ability to define a HiveMind
> >>>>>>service in terms
> >>>>>> of a Spring bean within a BeanFactory. The essential code is:
> >>>>>>
> >>>>>> public Object createCoreServiceImplementation(
> >>>>>> ServiceImplementationFactoryParameters
> >>>>>>factoryParameters)
> >>>>>> {
> >>>>>> SpringBeanParameter p = (SpringBeanParameter)
> >>>>>> factoryParameters.getFirstParameter();
> >>>>>> String beanName = p.getName();
> >>>>>>
> >>>>>> BeanFactory f = p.getBeanFactory();
> >>>>>>
> >>>>>> if (f == null)
> >>>>>> f = _defaultBeanFactory;
> >>>>>>
> >>>>>> return f.getBean(beanName,
> >>>>>>factoryParameters.getServiceInterface());
> >>>>>> }
> >>>>>>
> >>>>>> With this, its possible to obtain a Spring bean and the core
> >>>>>>service
> >>>>>> implementation of a HiveMind service. The implementation
> >>>>>>can be
> >>>>>> extended with interceptors and injected into other HiveMind
> >>>>>>services.
> >>>>>>
> >>>>>> At Javapolis, I talked with Rod about having something
> >>>>>>similar going
> >>>>>> the other direction, allowing HiveMind services to be
> >>>>>>referencable
> >>>>>> (and injectable) as Spring beans. I'd like to provoke a
> >>>>>>discussion on
> >>>>>> what that would look like, and what API changes would be
> >>>>>>needed in
> >>>>>> HiveMind 1.1 to support it.
> >>>>>>
> >>>>>> Rod seemed to think (and I didn't follow the reasoning) that
> >>>>>>HiveMind
> >>>>>> would need an API to iterate over the names of all services.
> >>>>>>
> >>>>>> In addition, configuration data (in either List or Map form)
> >>>>>>is also
> >>>>>> quite valuable and something that Spring beans would like to
> >>>>>>have
> >>>>>> access to.
> >>>>>>
> >>>>>> --
> >>>>>> Howard M. Lewis Ship
> >>>>>> Independent J2EE / Open-Source Java Consultant
> >>>>>> Creator, Jakarta Tapestry
> >>>>>> Creator, Jakarta HiveMind
> >>>>>>
> >>>>>> Professional Tapestry training, mentoring, support
> >>>>>> and project work. http://howardlewisship.com
> >>>>>>
> >>>>>>
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
> Tool for open source databases. Create drag-&-drop reports. Save time
> by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
> Download a FREE copy at http://www.intelliview.com/go/osdn_nl
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
|
|
From: Howard L. S. <hl...@gm...> - 2005-02-01 13:53:06
|
I think you are right about having all the integration code in one
place. I'd appreciate some help in terms of what the necessary Spring
code will look like, but it can certainly live in HiveMind.
We should allow the Spring support code to either start up a default
registry, or to accept a HiveMind registry as a
configurable/injectable value. We won't know which side, if any, is
"running the show".
Don't forget about the configurations side of things! Certainly, you
can consider configurations to just be properties of services, but
they are in fact stand alone., and it would be very useful for Spring
to have HiveMind configurations injected into Spring services (as
either a List or Map property).
On Sat, 29 Jan 2005 11:55:22 -0500, jbetancourt <jbe...@co...> wrote:
> Why not just go a little further and provide a generic IoC interface? That
> is, a way for any IoC Container (IoCC) to interact with another.
>
> Though there are only a few IoCCs now, there may be more later, or there may
> be things that are similar, like EJB3 stuff. As with hierarchical
> containers, you sometimes don't care which level a bean comes from, you also
> don't care which container is really providing a service. Thus, an
> application could possibly mix container frameworks and target them where
> they provide more value-add. Sounds unlikely I guess.
>
>
> ----- Original Message -----
> From: "Colin Sampaleanu" <col...@ex...>
> To: <spr...@li...>
>
> Sent: Saturday, January 29, 2005 10:13 AM
> Subject: Re: [Springframework-developer] Spring / HiveMind Integration
>
> > Yes, I have to agree this probably makes sense... It's a little less
> > convenient, but resolves versioning issues. One question is whether you
> > can do a good enough integration that way, but I would that would not be
> > an issue, it's not like you want to make one container dependent on the
> > other anyway at it's core, so any integration should be at a higher level.
> >
> >
> > Juergen Hoeller wrote:
> >
> > >I was mainly wondering whether it makes sense to separate HiveMind/Spring
> > >integration and Spring/HiveMind integration... Shouldn't we put both into
> > >the *same* distribution?
> > >
> > >Juergen
> > >
> > >
> > >-----Original Message-----
> > >From: spr...@li...
> > >[mailto:spr...@li...]On Behalf
> > >Of Rob Harrop
> > >Sent: Saturday, January 29, 2005 3:27 PM
> > >To: spr...@li...
> > >Subject: Re: [Springframework-developer] Spring / HiveMind Integration
> > >
> > >
> > >I was thinking of distributing this as one of the first things in the a
> > >separate project containing extensions and add-ons to Spring. I've been
> > >working on a couple of other modules as well which I think should be
> > >kept separate from the core.
> > >
> > >Rob
> > >
> > >Juergen Hoeller wrote:
> > >
> > >
> > >
> > >>I guess the problem is also about shipping. If HiveMind ships with
> Spring,
> > >>and Spring would then ship with HiveMind too, it seems to me that we
> could
> > >>simplify this: Why not put all Spring/HiveMind integration code into
> > >>HiveMind Extras or a Spring-HiveMind project or the like? There would a
> > >>single place to maintain both ways of integration then, for specific
> > >>versions of Spring and HiveMind.
> > >>
> > >>Even if we included HiveMind integration in Spring, we would have to do
> > >>
> > >>
> > >this
> > >
> > >
> > >>in a separate distribution, Spring Extras or whatever it would be
> called.
> > >>
> > >>
> > >It
> > >
> > >
> > >>is certainly not feasible to extend the dependencies of the core Spring
> > >>distribution to integration with other lightweight containers, given
> that
> > >>
> > >>
> > >we
> > >
> > >
> > >>already ship all sorts of persistence and web view libraries etc.
> > >>
> > >>Juergen
> > >>
> > >>
> > >>-----Original Message-----
> > >>From: spr...@li...
> > >>[mailto:spr...@li...]On Behalf
> > >>Of Rob Harrop
> > >>Sent: Saturday, January 29, 2005 2:54 PM
> > >>To: spr...@li...
> > >>Subject: Re: [Springframework-developer] Spring / HiveMind Integration
> > >>
> > >>
> > >>That is a concern, and I guess we could put in hooks to prevent this -
> > >>but I think it is probably simpler to say "Don't do this!".
> > >>
> > >>Rob
> > >>
> > >>Colin Sampaleanu wrote:
> > >>
> > >>
> > >>
> > >>
> > >>
> > >>>I'm not sure it really matters, but given that Hivemind already has
> > >>>Spring integration code, and we are talking about Hivemind
> > >>>integration code for Spring, nobody has mentioned that we're going to
> > >>>end up with a circular dependency here... There are some potential
> > >>>versioning issues, but I guess they are a concern if you want to call
> > >>>
> > >>>
> > >>>from Spring to Hivemind back to Spring, or Hivemind to Spring back to
> > >>
> > >>
> > >>>Hivemind...
> > >>>
> > >>>Rob Harrop wrote:
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>>Howard,
> > >>>>
> > >>>>I think it will be quite simple to integrate HiveMind services into
> > >>>>Spring. As I see it we need a HiveMindRegistryFactoryBean to create
> > >>>>the Registry instance and then a HiveMindServiceFactoryBean that uses
> > >>>>the Registry to lookup a given service. By default the
> > >>>>HiveMindServiceFactoryBean would use the Spring bean name to lookup a
> > >>>>service in the Registry, but users could configure a different
> > >>>>service name using DI. With this mechanism, users can create one
> > >>>>instance of Registry within a Spring application and then access many
> > >>>>services from that Registry.
> > >>>>
> > >>>>If I have time today, I'll work on this. If not, I'll work on it next
> > >>>>week some time.
> > >>>>
> > >>>>Rob
> > >>>>
> > >>>>Howard Lewis Ship wrote:
> > >>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>>>This comes up quite a bit, they are similiar in intent but quite
> > >>>>>different in execution.
> > >>>>>
> > >>>>>- HiveMind has a very sophisiticated configurations model (very
> > >>>>>similar to Eclipse plugins) based on configuration points and
> > >>>>>contributions (from multiple locations)
> > >>>>>- HiveMind is the infrastructure for Tapestry 3.1, and many Tapestry
> > >>>>>applications also use Spring
> > >>>>>- Because Rod and I (and the other Spring team member's I've talked
> > >>>>>to) want to foster cooperation and compatability rather than
> > >>>>>competition
> > >>>>>
> > >>>>>
> > >>>>>On Fri, 28 Jan 2005 10:47:48 +1100, Mason, Ross
> > >>>>><ros...@vi...> wrote:
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>>Hi Howard,
> > >>>>>>
> > >>>>>>What is the use case for integrating HiveMind and Spring? I must
> > >>>>>>admit I haven't had a chance to get a good look at HiveMind, but my
> > >>>>>>understanding is that it is a DI container that provides service
> > >>>>>>wiring and interception, much in the same vein as the Spring
> > >>>>>>Container. From the outset the two containers seem to be mutally
> > >>>>>>exclusive rather than complimentary.
> > >>>>>>
> > >>>>>>Can you shed some light on this for me?
> > >>>>>>
> > >>>>>>Cheers,
> > >>>>>>
> > >>>>>>Ross
> > >>>>>>
> > >>>>>> -----Original Message-----
> > >>>>>> From: spr...@li...
> > >>>>>>on behalf of Howard Lewis Ship
> > >>>>>> Sent: Wed 26/01/2005 2:46 PM
> > >>>>>> To: spr...@li...
> > >>>>>> Cc:
> > >>>>>> Subject: [Springframework-developer] Spring / HiveMind
> > >>>>>>Integration
> > >>>>>>
> > >>>>>> Since HiveMind 1.0, and improved in HiveMind 1.1, there's
> > >>>>>>been basic
> > >>>>>> integration between HiveMind and Spring.
> > >>>>>>
> > >>>>>> At the core of it is the ability to define a HiveMind
> > >>>>>>service in terms
> > >>>>>> of a Spring bean within a BeanFactory. The essential code is:
> > >>>>>>
> > >>>>>> public Object createCoreServiceImplementation(
> > >>>>>> ServiceImplementationFactoryParameters
> > >>>>>>factoryParameters)
> > >>>>>> {
> > >>>>>> SpringBeanParameter p = (SpringBeanParameter)
> > >>>>>> factoryParameters.getFirstParameter();
> > >>>>>> String beanName = p.getName();
> > >>>>>>
> > >>>>>> BeanFactory f = p.getBeanFactory();
> > >>>>>>
> > >>>>>> if (f == null)
> > >>>>>> f = _defaultBeanFactory;
> > >>>>>>
> > >>>>>> return f.getBean(beanName,
> > >>>>>>factoryParameters.getServiceInterface());
> > >>>>>> }
> > >>>>>>
> > >>>>>> With this, its possible to obtain a Spring bean and the core
> > >>>>>>service
> > >>>>>> implementation of a HiveMind service. The implementation
> > >>>>>>can be
> > >>>>>> extended with interceptors and injected into other HiveMind
> > >>>>>>services.
> > >>>>>>
> > >>>>>> At Javapolis, I talked with Rod about having something
> > >>>>>>similar going
> > >>>>>> the other direction, allowing HiveMind services to be
> > >>>>>>referencable
> > >>>>>> (and injectable) as Spring beans. I'd like to provoke a
> > >>>>>>discussion on
> > >>>>>> what that would look like, and what API changes would be
> > >>>>>>needed in
> > >>>>>> HiveMind 1.1 to support it.
> > >>>>>>
> > >>>>>> Rod seemed to think (and I didn't follow the reasoning) that
> > >>>>>>HiveMind
> > >>>>>> would need an API to iterate over the names of all services.
> > >>>>>>
> > >>>>>> In addition, configuration data (in either List or Map form)
> > >>>>>>is also
> > >>>>>> quite valuable and something that Spring beans would like to
> > >>>>>>have
> > >>>>>> access to.
> > >>>>>>
> > >>>>>> --
> > >>>>>> Howard M. Lewis Ship
> > >>>>>> Independent J2EE / Open-Source Java Consultant
> > >>>>>> Creator, Jakarta Tapestry
> > >>>>>> Creator, Jakarta HiveMind
> > >>>>>>
> > >>>>>> Professional Tapestry training, mentoring, support
> > >>>>>> and project work. http://howardlewisship.com
> > >>>>>>
> > >>>>>>
> >
> >
> >
> > -------------------------------------------------------
> > This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
> > Tool for open source databases. Create drag-&-drop reports. Save time
> > by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
> > Download a FREE copy at http://www.intelliview.com/go/osdn_nl
> > _______________________________________________
> > Springframework-developer mailing list
> > Spr...@li...
> > https://lists.sourceforge.net/lists/listinfo/springframework-developer
> >
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
> Tool for open source databases. Create drag-&-drop reports. Save time
> by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
> Download a FREE copy at http://www.intelliview.com/go/osdn_nl
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
--
Howard M. Lewis Ship
Independent J2EE / Open-Source Java Consultant
Creator, Jakarta Tapestry
Creator, Jakarta HiveMind
Professional Tapestry training, mentoring, support
and project work. http://howardlewisship.com
|
|
From: Rob H. <ro...@ca...> - 2005-02-01 14:02:48
|
Howard,
I'm going to spend some time tonight to put some code together for this.
I'll send it over to you.
Rob
Howard Lewis Ship wrote:
>I think you are right about having all the integration code in one
>place. I'd appreciate some help in terms of what the necessary Spring
>code will look like, but it can certainly live in HiveMind.
>
>We should allow the Spring support code to either start up a default
>registry, or to accept a HiveMind registry as a
>configurable/injectable value. We won't know which side, if any, is
>"running the show".
>
>Don't forget about the configurations side of things! Certainly, you
>can consider configurations to just be properties of services, but
>they are in fact stand alone., and it would be very useful for Spring
>to have HiveMind configurations injected into Spring services (as
>either a List or Map property).
>
>
>On Sat, 29 Jan 2005 11:55:22 -0500, jbetancourt <jbe...@co...> wrote:
>
>
>>Why not just go a little further and provide a generic IoC interface? That
>>is, a way for any IoC Container (IoCC) to interact with another.
>>
>>Though there are only a few IoCCs now, there may be more later, or there may
>>be things that are similar, like EJB3 stuff. As with hierarchical
>>containers, you sometimes don't care which level a bean comes from, you also
>>don't care which container is really providing a service. Thus, an
>>application could possibly mix container frameworks and target them where
>>they provide more value-add. Sounds unlikely I guess.
>>
>>
>>----- Original Message -----
>>From: "Colin Sampaleanu" <col...@ex...>
>>To: <spr...@li...>
>>
>>Sent: Saturday, January 29, 2005 10:13 AM
>>Subject: Re: [Springframework-developer] Spring / HiveMind Integration
>>
>>
>>
>>>Yes, I have to agree this probably makes sense... It's a little less
>>>convenient, but resolves versioning issues. One question is whether you
>>>can do a good enough integration that way, but I would that would not be
>>>an issue, it's not like you want to make one container dependent on the
>>>other anyway at it's core, so any integration should be at a higher level.
>>>
>>>
>>>Juergen Hoeller wrote:
>>>
>>>
>>>
>>>>I was mainly wondering whether it makes sense to separate HiveMind/Spring
>>>>integration and Spring/HiveMind integration... Shouldn't we put both into
>>>>the *same* distribution?
>>>>
>>>>Juergen
>>>>
>>>>
>>>>-----Original Message-----
>>>>From: spr...@li...
>>>>[mailto:spr...@li...]On Behalf
>>>>Of Rob Harrop
>>>>Sent: Saturday, January 29, 2005 3:27 PM
>>>>To: spr...@li...
>>>>Subject: Re: [Springframework-developer] Spring / HiveMind Integration
>>>>
>>>>
>>>>I was thinking of distributing this as one of the first things in the a
>>>>separate project containing extensions and add-ons to Spring. I've been
>>>>working on a couple of other modules as well which I think should be
>>>>kept separate from the core.
>>>>
>>>>Rob
>>>>
>>>>Juergen Hoeller wrote:
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>>I guess the problem is also about shipping. If HiveMind ships with
>>>>>
>>>>>
>>Spring,
>>
>>
>>>>>and Spring would then ship with HiveMind too, it seems to me that we
>>>>>
>>>>>
>>could
>>
>>
>>>>>simplify this: Why not put all Spring/HiveMind integration code into
>>>>>HiveMind Extras or a Spring-HiveMind project or the like? There would a
>>>>>single place to maintain both ways of integration then, for specific
>>>>>versions of Spring and HiveMind.
>>>>>
>>>>>Even if we included HiveMind integration in Spring, we would have to do
>>>>>
>>>>>
>>>>>
>>>>>
>>>>this
>>>>
>>>>
>>>>
>>>>
>>>>>in a separate distribution, Spring Extras or whatever it would be
>>>>>
>>>>>
>>called.
>>
>>
>>>>>
>>>>>
>>>>It
>>>>
>>>>
>>>>
>>>>
>>>>>is certainly not feasible to extend the dependencies of the core Spring
>>>>>distribution to integration with other lightweight containers, given
>>>>>
>>>>>
>>that
>>
>>
>>>>>
>>>>>
>>>>we
>>>>
>>>>
>>>>
>>>>
>>>>>already ship all sorts of persistence and web view libraries etc.
>>>>>
>>>>>Juergen
>>>>>
>>>>>
>>>>>-----Original Message-----
>>>>>From: spr...@li...
>>>>>[mailto:spr...@li...]On Behalf
>>>>>Of Rob Harrop
>>>>>Sent: Saturday, January 29, 2005 2:54 PM
>>>>>To: spr...@li...
>>>>>Subject: Re: [Springframework-developer] Spring / HiveMind Integration
>>>>>
>>>>>
>>>>>That is a concern, and I guess we could put in hooks to prevent this -
>>>>>but I think it is probably simpler to say "Don't do this!".
>>>>>
>>>>>Rob
>>>>>
>>>>>Colin Sampaleanu wrote:
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>I'm not sure it really matters, but given that Hivemind already has
>>>>>>Spring integration code, and we are talking about Hivemind
>>>>>>integration code for Spring, nobody has mentioned that we're going to
>>>>>>end up with a circular dependency here... There are some potential
>>>>>>versioning issues, but I guess they are a concern if you want to call
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>from Spring to Hivemind back to Spring, or Hivemind to Spring back to
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>Hivemind...
>>>>>>
>>>>>>Rob Harrop wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>Howard,
>>>>>>>
>>>>>>>I think it will be quite simple to integrate HiveMind services into
>>>>>>>Spring. As I see it we need a HiveMindRegistryFactoryBean to create
>>>>>>>the Registry instance and then a HiveMindServiceFactoryBean that uses
>>>>>>>the Registry to lookup a given service. By default the
>>>>>>>HiveMindServiceFactoryBean would use the Spring bean name to lookup a
>>>>>>>service in the Registry, but users could configure a different
>>>>>>>service name using DI. With this mechanism, users can create one
>>>>>>>instance of Registry within a Spring application and then access many
>>>>>>>services from that Registry.
>>>>>>>
>>>>>>>If I have time today, I'll work on this. If not, I'll work on it next
>>>>>>>week some time.
>>>>>>>
>>>>>>>Rob
>>>>>>>
>>>>>>>Howard Lewis Ship wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>This comes up quite a bit, they are similiar in intent but quite
>>>>>>>>different in execution.
>>>>>>>>
>>>>>>>>- HiveMind has a very sophisiticated configurations model (very
>>>>>>>>similar to Eclipse plugins) based on configuration points and
>>>>>>>>contributions (from multiple locations)
>>>>>>>>- HiveMind is the infrastructure for Tapestry 3.1, and many Tapestry
>>>>>>>>applications also use Spring
>>>>>>>>- Because Rod and I (and the other Spring team member's I've talked
>>>>>>>>to) want to foster cooperation and compatability rather than
>>>>>>>>competition
>>>>>>>>
>>>>>>>>
>>>>>>>>On Fri, 28 Jan 2005 10:47:48 +1100, Mason, Ross
>>>>>>>><ros...@vi...> wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>Hi Howard,
>>>>>>>>>
>>>>>>>>>What is the use case for integrating HiveMind and Spring? I must
>>>>>>>>>admit I haven't had a chance to get a good look at HiveMind, but my
>>>>>>>>>understanding is that it is a DI container that provides service
>>>>>>>>>wiring and interception, much in the same vein as the Spring
>>>>>>>>>Container. From the outset the two containers seem to be mutally
>>>>>>>>>exclusive rather than complimentary.
>>>>>>>>>
>>>>>>>>>Can you shed some light on this for me?
>>>>>>>>>
>>>>>>>>>Cheers,
>>>>>>>>>
>>>>>>>>>Ross
>>>>>>>>>
>>>>>>>>> -----Original Message-----
>>>>>>>>> From: spr...@li...
>>>>>>>>>on behalf of Howard Lewis Ship
>>>>>>>>> Sent: Wed 26/01/2005 2:46 PM
>>>>>>>>> To: spr...@li...
>>>>>>>>> Cc:
>>>>>>>>> Subject: [Springframework-developer] Spring / HiveMind
>>>>>>>>>Integration
>>>>>>>>>
>>>>>>>>> Since HiveMind 1.0, and improved in HiveMind 1.1, there's
>>>>>>>>>been basic
>>>>>>>>> integration between HiveMind and Spring.
>>>>>>>>>
>>>>>>>>> At the core of it is the ability to define a HiveMind
>>>>>>>>>service in terms
>>>>>>>>> of a Spring bean within a BeanFactory. The essential code is:
>>>>>>>>>
>>>>>>>>> public Object createCoreServiceImplementation(
>>>>>>>>> ServiceImplementationFactoryParameters
>>>>>>>>>factoryParameters)
>>>>>>>>> {
>>>>>>>>> SpringBeanParameter p = (SpringBeanParameter)
>>>>>>>>> factoryParameters.getFirstParameter();
>>>>>>>>> String beanName = p.getName();
>>>>>>>>>
>>>>>>>>> BeanFactory f = p.getBeanFactory();
>>>>>>>>>
>>>>>>>>> if (f == null)
>>>>>>>>> f = _defaultBeanFactory;
>>>>>>>>>
>>>>>>>>> return f.getBean(beanName,
>>>>>>>>>factoryParameters.getServiceInterface());
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>> With this, its possible to obtain a Spring bean and the core
>>>>>>>>>service
>>>>>>>>> implementation of a HiveMind service. The implementation
>>>>>>>>>can be
>>>>>>>>> extended with interceptors and injected into other HiveMind
>>>>>>>>>services.
>>>>>>>>>
>>>>>>>>> At Javapolis, I talked with Rod about having something
>>>>>>>>>similar going
>>>>>>>>> the other direction, allowing HiveMind services to be
>>>>>>>>>referencable
>>>>>>>>> (and injectable) as Spring beans. I'd like to provoke a
>>>>>>>>>discussion on
>>>>>>>>> what that would look like, and what API changes would be
>>>>>>>>>needed in
>>>>>>>>> HiveMind 1.1 to support it.
>>>>>>>>>
>>>>>>>>> Rod seemed to think (and I didn't follow the reasoning) that
>>>>>>>>>HiveMind
>>>>>>>>> would need an API to iterate over the names of all services.
>>>>>>>>>
>>>>>>>>> In addition, configuration data (in either List or Map form)
>>>>>>>>>is also
>>>>>>>>> quite valuable and something that Spring beans would like to
>>>>>>>>>have
>>>>>>>>> access to.
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Howard M. Lewis Ship
>>>>>>>>> Independent J2EE / Open-Source Java Consultant
>>>>>>>>> Creator, Jakarta Tapestry
>>>>>>>>> Creator, Jakarta HiveMind
>>>>>>>>>
>>>>>>>>> Professional Tapestry training, mentoring, support
>>>>>>>>> and project work. http://howardlewisship.com
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>
>>>-------------------------------------------------------
>>>This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
>>>Tool for open source databases. Create drag-&-drop reports. Save time
>>>by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
>>>Download a FREE copy at http://www.intelliview.com/go/osdn_nl
>>>_______________________________________________
>>>Springframework-developer mailing list
>>>Spr...@li...
>>>https://lists.sourceforge.net/lists/listinfo/springframework-developer
>>>
>>>
>>>
>>-------------------------------------------------------
>>This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
>>Tool for open source databases. Create drag-&-drop reports. Save time
>>by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
>>Download a FREE copy at http://www.intelliview.com/go/osdn_nl
>>_______________________________________________
>>Springframework-developer mailing list
>>Spr...@li...
>>https://lists.sourceforge.net/lists/listinfo/springframework-developer
>>
>>
>>
>
>
>
>
|
