Menu
▾
▴
springframework-developer
|
From: <jue...@we...> - 2003-07-11 14:36:15
|
Hi Ivan, Component lifecycles have already been discussed at some time, but the = current support is rather minimal as there hasn't been much need for = more sophisticated one yet. Currently, we offer 3 kinds of initialization callbacks: - "InitializingBean": just an "afterPropertiesSet()" callback after = populating the bean properties;=20 - "BeanFactoryAware": a "setBeanFactory(BeanFactory)" callback to supply = the containing factory to the bean instance; - "ApplicationContextAware": a = "setApplicationContext(ApplicationContext)" callback to supply the = containing context to the bean instance. The latter is only available within a Spring application context, = offering not just bean factory capabilities but also pluggable message = sources, resource retrieval (adapted per environment, e.g. file / = classpath / web context), etc. There's also a convenient = "ApplicationObjectSupport" base class that implements it, providing an = "initApplicationContext()" callback. InitializingBean is often used for simple initialization that depends on = multiple bean properties, without making the bean aware of anything = else. BeanFactoryAware is rarely necessary, as most bean references can = be supplied via respective bean properties anyway. = ApplicationContextAware provides the bean with full capabilities of a = Spring application context, e.g. for retrieving custom config files. Introducing a service lifecycle interface (with start/stop callbacks) = and reconfiguration capabilities should be straightforward. You are very = welcome to join us and work on this! Rod and me will be happy to provide = you with details on the current bean factory and application context = concepts :-) Regards, Juergen -----Original Message----- From: Ivan Ristic [mailto:iv...@we...] Sent: Friday, July 11, 2003 2:01 PM To: spr...@li... Subject: [Springframework-developer] JavaBeans lifecycle considerations? I read the container documentation at=20 http://www.springframework.org/docs/lightweight_container.html with great interest. I really like the "natural" JavaBeans approach. Are there any mechanisms in the container framework to handle component lifecycle? Such as start (possibly to run on its own thread), stop, dispose? There is one sentence in the document where you talk how Spring will support reconfiguration in the future. Are there any concrete plans for this or are other developers (such as myself 0:) invited to join and suggest ideas? I have some ideas and I would rather implement them as part of an existing framework than create yet-another-framework that no one except me will use. --=20 ModSecurity (http://www.modsecurity.org) [ Open source IDS for Web applications ] ------------------------------------------------------- This SF.Net email sponsored by: Parasoft Error proof Web apps, automate testing & more. Download & eval WebKing and get a free book. www.parasoft.com/bulletproofapps1 _______________________________________________ Springframework-developer mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springframework-developer |
|
From: <rod...@in...> - 2003-07-11 15:17:28
|
>Introducing a service lifecycle interface (with start/stop callbacks) and reconfiguration capabilities should be straightforward. You are very welcome to join us and work on this! Yes, contribution is very welcome. Please note that this is definitely something for the 1.1 release, not 1.0. As Juergen noted, so far we haven't had much need for a stop() concept. Perhaps it would be a good start to formulate your requirements, and what enhancements the Spring lifecycle might need to support to address them. Regards, Rod |
|
From: Ivan R. <iv...@we...> - 2003-07-12 16:41:19
|
> Yes, contribution is very welcome. Please note that this is > definitely something for the 1.1 release, not 1.0. Not a problem. I am not in a hurry, i.e. I don't have a project with a deadline. I can also implement changes on a separate branch and merge them later. -- ModSecurity (http://www.modsecurity.org) [ Open source IDS for Web applications ] |
|
From: <jue...@we...> - 2003-07-11 15:22:50
|
UC5TLjogSSd2ZSBvYnZpb3VzbHkgcmVuYW1lZCBvdXIgYmVhbnMgIkxpZmVjeWNsZSIgdG8gIkJl YW5GYWN0b3J5QXdhcmUiIChhbHJlYWR5IGNvbW1pdHRlZCksIGJlY2F1c2UgdGhhdCdzIHdoYXQg aXQgcmVhbGx5IGlzIGF0IHRoZSBtb21lbnQsIGp1c3QgbGlrZSBBcHBsaWNhdGlvbkNvbnRleHRB d2FyZS4NCg0KQlRXLCBJJ3ZlIGp1c3QgdGFnZ2VkICJyZWxlYXNlLTAuOSIsIHNwZWNpZnlpbmcg MjAwMy0wNi0yNiBhcyBkYXRlLiBUaGF0IG1lYW5zIHdlIG5vdyBoYXZlIGEgcHJvcGVyIDAuOSB0 YWcsIGRlc3BpdGUgbXkgb3JpZ2luYWwgZm9yZ2V0ZnVsbmVzcy4uLg0KDQpKdWVyZ2VuDQoNCg0K LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IHJvZC5qb2huc29uQGludGVyZmFjZTIx LmNvbSBbbWFpbHRvOnJvZC5qb2huc29uQGludGVyZmFjZTIxLmNvbV0NClNlbnQ6IEZyaWRheSwg SnVseSAxMSwgMjAwMyA1OjE3IFBNDQpUbzogasO8cmdlbiBow7ZsbGVyIFt3ZXJrM0FUXQ0KQ2M6 IEl2YW4gUmlzdGljOyBzcHJpbmdmcmFtZXdvcmstZGV2ZWxvcGVyQGxpc3RzLnNvdXJjZWZvcmdl Lm5ldA0KU3ViamVjdDogUkU6IFtTcHJpbmdmcmFtZXdvcmstZGV2ZWxvcGVyXSBKYXZhQmVhbnMg bGlmZWN5Y2xlDQpjb25zaWRlcmF0aW9ucz8NCg0KDQo+SW50cm9kdWNpbmcgYSBzZXJ2aWNlIGxp ZmVjeWNsZSBpbnRlcmZhY2UgKHdpdGggc3RhcnQvc3RvcCANCmNhbGxiYWNrcykgYW5kIHJlY29u ZmlndXJhdGlvbiBjYXBhYmlsaXRpZXMgc2hvdWxkIGJlIA0Kc3RyYWlnaHRmb3J3YXJkLiBZb3Ug YXJlIHZlcnkgd2VsY29tZSB0byBqb2luIHVzIGFuZCB3b3JrIG9uIA0KdGhpcyEgDQoNClllcywg Y29udHJpYnV0aW9uIGlzIHZlcnkgd2VsY29tZS4gUGxlYXNlIG5vdGUgdGhhdCB0aGlzIGlzIA0K ZGVmaW5pdGVseSBzb21ldGhpbmcgZm9yIHRoZSAxLjEgcmVsZWFzZSwgbm90IDEuMC4gQXMgSnVl cmdlbiANCm5vdGVkLCBzbyBmYXIgd2UgaGF2ZW4ndCBoYWQgbXVjaCBuZWVkIGZvciBhIHN0b3Ao KSBjb25jZXB0LiANClBlcmhhcHMgaXQgd291bGQgYmUgYSBnb29kIHN0YXJ0IHRvIGZvcm11bGF0 ZSB5b3VyIA0KcmVxdWlyZW1lbnRzLCBhbmQgd2hhdCBlbmhhbmNlbWVudHMgdGhlIFNwcmluZyBs aWZlY3ljbGUgDQptaWdodCBuZWVkIHRvIHN1cHBvcnQgdG8gYWRkcmVzcyB0aGVtLg0KDQpSZWdh cmRzLA0KUm9kDQo= |
|
From: <jue...@we...> - 2003-07-13 11:40:06
|
SGkgSXZhbiwNCiANCkludGVyZXN0aW5nIHN0dWZmISBXZSBkbyBjb21wZXRlIHdpdGggYm90aCBB dmFsb24gYW5kIFBpY29Db250YWluZXIgaW4gdGhhdCByZXNwZWN0LCBhbHRob3VnaCBBdmFsb24g aXMgZmFyIG1vcmUgY29tcGxleCB0aGFuIFBpY29Db250YWluZXIgZnJvbSBteSBwb2ludCBvZiB2 aWV3LiBJIGRpZG4ndCBrbm93IGFib3V0IEhpdmVNaW5kIHlldCwgaXQgZG9lc24ndCBzZWVtIHBh cnRpY3VsYXJseSBjb252aW5jaW5nIHRob3VnaC4gQW55d2F5LCBJIGNvbnNpZGVyIFNwcmluZydz IGJlYW4tY2VudHJpYyBhcHByb2FjaCBzbyBzaW1wbGUsIG5vbi1pbnRydXNpdmUsIGFuZCBwb3dl cmZ1bCB0aGF0IGl0IGlzIHJlYWxseSBoYXJkIHRvIGJlYXQgOi0pDQogDQpDb25jZXJuaW5nIHlv dXIgcmVxdWlyZW1lbnRzOg0KIA0KKiBDb21wbGV0ZSBiZWFuIGxpZmUgY3ljbGU6IHBhcmFtZXRl cnMsIGluaXRpYWxpc2F0aW9uLCBzdGFydCwgc3RvcCwgc3VzcGVuZCwgcmVzdW1lLCByZWNvbmZp Z3VyZSwgZGlzcG9zZS9kZXN0cm95DQoNCkkgYWdyZWUgdGhhdCBhIHNpbmdsZSBwYWlyIG9mIHN0 YXJ0L3N0b3AgbWV0aG9kcyBzaG91bGQgZG8gdGhlIGpvYiwgbm8gbmVlZCBmb3IgYSBzdXNwZW5k L3Jlc3VtZS4gVGhpcyBjb3VsZCBiZSBtb2RlbGxlZCBhcyBhICJTdGFydGFibGUiIGludGVyZmFj ZS4gQSBzZXBhcmF0ZSAiRGlzcG9zYWJsZSIgaW50ZXJmYWNlIGNvdWxkIGZlYXR1cmUgYSBkaXNw b3NlIG1ldGhvZCBmb3IgY2xlYW51cCBwdXJwb3NlcyBvbiBzaHV0ZG93bi4NCg0KKiBCZWFucyB0 aGF0IHdhbnQgdG8gY2FuIGV4ZWN1dGUgb24gdGhlaXIgb3duIHRocmVhZA0KDQpIb3cgaXMgdGhp cyBzdXBwb3NlZCB0byB3b3JrPyBUaGUgZXhlY3V0aW9uIHRocmVhZCBpcyBhbHdheXMgZGV0ZXJt aW5lZCBieSB0aGUgY2FsbGVyIG9mIGEgYmVhbidzIG1ldGhvZHMuIEluIHRoYXQgcmVzcGVjdCwg YSBiZWFuIGNhbid0IGV4ZWN1dGUgIm9uIGl0cyBvd24gdGhyZWFkIiwgaWYgSSB1bmRlcnN0YW5k IGNvcnJlY3RseS4gQSBiZWFuIGNhbiAqY3JlYXRlKiBpdHMgb3duIHRocmVhZHMgdGhvdWdoLCBl aXRoZXIgb24gaW5pdGlhbGl6YXRpb24gb3Igb24gY2VydGFpbiBtZXRob2QgY2FsbHMuIEJ1dCBp biBhbnkgY2FzZSwgdGhlIG1haW4gbWV0aG9kIGludm9jYXRpb24gd2lsbCBhbHdheXMgZXhlY3V0 ZSBpbiB0aGUgY2FsbGVyJ3MgdGhyZWFkLiBUaGVyZWZvcmUgSSBkb24ndCB0aGluayB0aGF0IHdl IG5lZWQgIm93biB0aHJlYWQiIHN1cHBvcnQuIFNwcmluZyBzaW1wbHkgdHJlYXRzIHN1Y2ggdGhy ZWFkIHN0YXJ0ZXJzIGFzIGNvbnZlbnRpb25hbCBiZWFucywgaW5pdGlhbGl6aW5nIHRoZW0gYW5k IG1ha2luZyB0aGVtIGF2YWlsYWJsZS4gSXQgZG9lc24ndCBjYXJlIGlmIGFuZCB3aGVuIGEgYmVh biBzdGFydHMgYW5kIHN0b3BzIG5ldyB0aHJlYWRzIC0gdGhhdCdzIHRoZSBiZWFuJ3MgcmVzcG9u c2liaWxpdHkuDQoNCiogU2luZ2xldG9uL3NoYXJlZCBhbmQgbm90LXNoYXJlZCBiZWFucw0KKiBC ZWFuIHBvb2xzIChjaGVjay1pbiwgY2hlY2stb3V0KQ0KDQpBcyB5b3UndmUgbm90ZWQsIFNwcmlu ZyBhbHJlYWR5IHN1cHBvcnRzIHRoZSBmaXJzdCB0d28gbm90aW9ucy4gUmVnYXJkaW5nIGJlYW4g cG9vbHMsIEknbSBub3QgdG9vIGNvbnZpbmNlZCBpZiB0aGV5IGFjdHVhbGx5IGFkZCB2YWx1ZS4g SW4gY29udHJhc3QgdG8gRUpCcywgYmVhbnMgYXJlIGV4dHJlbWVseSBsaWdodHdlaWdodCwgdGhl IG9uLWRlbWFuZCBjcmVhdGlvbiBvdmVyaGVhZCBub3JtYWxseSBkb2Vzbid0IG1hdHRlci4gUGVy c29uYWxseSwgSSBqdXN0IHVzZSBzaW5nbGV0b24gYmVhbnMsIGFzIEkgZmluZCBoYXJkbHkgYW55 IHNjZW5hcmlvcyB3aGVyZSBJIGNvdWxkbid0IHdyaXRlIGEgdGhyZWFkLXNhZmUsIHJldXNhYmxl IGJlYW4uIEV2ZW4gd2hlbiBleHBvcnRpbmcgcmVtb3RlIGJlYW5zIHZpYSBIZXNzaWFuIC8gQnVy bGFwIC8gUk1JIC8gU09BUCAvIHdoYXRldmVyLCBpdCBzaG91bGQgYWx3YXlzIGJlIHBvc3NpYmxl IHRvIHdyaXRlIGEgc2luZ2xlIHRocmVhZC1zYWZlIGJlYW4gaW5zdGFuY2UuDQogDQpJbnN0YW5j ZSBwb29saW5nIHdvdWxkIGFkZCBhIHNpZ25pZmljYW50IGFtb3VudCBvZiBvdmVyaGVhZDogVGhl cmUgd291bGQgaW5kZWVkIGhhdmUgdG8gYmUgYW4gZXhwbGljaXQgY2hlY2tvdXQgYW5kIGNoZWNr aW4sIG9yIGEgdHJhbnNwYXJlbnQgY2hlY2tvdXQgLyBjaGVja2luIG9uIGVhY2ggbWV0aG9kIGlu dm9jYXRpb24sIHVzaW5nIGFuIGludm9jYXRpb24gcHJveHkgdGhhdCBkZWxlZ2F0ZXMgdG8gdGhl IGFjdHVhbCBwb29sZWQgaW5zdGFuY2UuIFRoYXQgbWF5IG1ha2Ugc2Vuc2UgZm9yIGFjY2VzcyB0 byBsb2FkLWJhbGFuY2VkIHJlbW90ZSBzZXJ2aWNlcywgYnV0IEkgcmVhbGx5IGRvdWJ0IHRoZSB2 YWx1ZSBmb3IgbG9jYWwgaW52b2NhdGlvbnMuIEkgc2ltcGx5IGRvbid0IHNlZSBhIG5lZWQgZm9y IG1vZGVsbGluZyBsb2NhbCBzZXJ2aWNlcyB0aGlzIHdheSwgZXZlbiBpZiBFSkIncyBTdGF0ZWxl c3MgU2Vzc2lvbiBCZWFucyBvZmZlciBzdWNoIHBvb2xpbmcgZm9yIGxvY2FsIGluc3RhbmNlcyB0 b28uDQogDQpJIGNvbnNpZGVyIFNMU0IgbXVsdGktdGhyZWFkaW5nIHN1cHBvcnQgc29tZXdoYXQg d29ydGhsZXNzLCBpLmUuIHRoYXQgdGhlcmUgd2lsbCBhbHdheXMgYmUganVzdCBvbmUgY29uY3Vy cmVudCBpbnZvY2F0aW9uIG9uIGFueSBnaXZlbiBpbnN0YW5jZSwgZ2l2aW5nIHJpc2UgdG8gdGhl IG5lZWQgZm9yIGluc3RhbmNlIHBvb2xzIHRvIHN1cHBvcnQgbXVsdGlwbGUgY29uY3VycmVudCBp bnZvY2F0aW9ucy4gVGhhdCBqdXN0IG1ha2VzIHNlbnNlIHdoZW4gdGhlcmUgYXJlIG5vbi10aHJl YWQtc2FmZSBpbnN0YW5jZSB2YXJpYWJsZXMgLSBidXQgSSBoYXZlbid0IHNlZW4gY29udmluY2lu ZyBleGFtcGxlcyBmb3Igc3VjaCByZXNvdXJjZXMuIEVpdGhlciB5b3UgY2FuIHNoYXJlIHRoZW0g d2l0aG91dCBoYXNzbGUsIGxpa2UgRGF0YVNvdXJjZXMgZXRjLCBvciB5b3UgY2FuIGNyZWF0ZSB0 aGVtIHdpdGhpbiBlYWNoIG1ldGhvZCBpbnZvY2F0aW9uLiBJbiBib3RoIGNhc2VzLCB0aGUgYmVh biBpbnN0YW5jZSBpcyBwZXJmZWN0bHkgdGhyZWFkLXNhZmUsIG11bHRpcGxlIGNvbmN1cnJlbnQg aW52b2NhdGlvbnMgYXJlIGZpbmUgLSB0aHVzIG5vIG5lZWQgZm9yIHBvb2xpbmcuIFNlcnZsZXRz IGFyZSBhIGdvb2QgZXhhbXBsZSB0b286IFNpbmdsZVRocmVhZE1vZGVsIGhhcyBldmVuIGJlZW4g ZGVwcmVjYXRlZCB0aGVyZSwgaW4gU2VydmxldCAyLjQuDQogDQoqIEFiaWxpdHkgdG8gc2FmZWx5 IHJlY29uZmlndXJlIGEgYmVhbiB0aGF0IGlzIHJlZmVyZW5jZWQgYnkgb3RoZXIgYmVhbnMNCiAN ClJlY29uZmlndXJhdGlvbiBpcyBpbmRlZWQgYW4gaW50ZXJlc3RpbmcgaXNzdWUsIGFzIGl0IG1h eSBuZWVkIHRvIGJsb2NrIHRoZSBzeXN0ZW0gdG8gZ3VhcmFudGVlIGNvbnNpc3RlbmN5OiBWYXJp b3VzIGNvbmZpZ3VyYXRpb24gY2hhbmdlcyBtaWdodCBkZXBlbmQgb24gZWFjaCBvdGhlciwgaS5l LiBuZWVkIHRvIGJlIGFwcGxpZWQgY29tcGxldGVseSBvciBub3QgYXQgYWxsIHRvIGtlZXAgdGhl IHN5c3RlbSBpbnRhY3QuIFRoaXMgaXMgc29tZXdoYXQgc2ltaWxhciB0byBhIGNsYXNzbG9hZGVy IHRoYXQgc3VwcG9ydHMgImhvdCIgY2xhc3MgcmVsb2FkaW5nLCBsaWtlIGluIGEgc2VydmxldCBj b250YWluZXI6IEVmZmVjdGl2ZWx5LCBpdCBjYW4ndCBiZSBndWFyYW50ZWVkIHRoYXQgdXBkYXRp bmcgYSBjbGFzcyB3b24ndCBicmVhayB0aGUgc3lzdGVtIGR1ZSB0byBhbGwga2luZHMgb2Ygc2lk ZSBlZmZlY3RzLiBUaHVzLCBob3QgY2xhc3MgcmVsb2FkaW5nIGlzIG1haW5seSBhIGRldmVsb3Bt ZW50IGZlYXR1cmUsIG5vdCByZWNvbW1lbmRlZCBmb3IgcHJvZHVjdGlvbiBlbnZpcm9ubWVudHMu DQogDQpGb3Igc3BlY2lmaWMgc2V0dGluZ3MgdGhhdCBhcmUgbG9jYWwgdG8gYSBzaW5nbGUgYmVh biwgImhvdCIgcmVjb25maWd1cmF0aW9uIHNob3VsZCBiZSBzb2x2YWJsZSB0aG91Z2guIEZvciBk ZXZlbG9wbWVudCBlbnZpcm9ubWVudHMsIG9uZSBjb3VsZCBzaW1wbHkgb3ZlcndyaXRlIHRoZSBy ZXNwZWN0aXZlIGJlYW4gcHJvcGVydGllcyBhbmQgcHJvY2VlZCAtIHRoaXMgd291bGQgYmUgZmlu ZSBpbiBtYW55IGNhc2VzLCBhdm9pZGluZyB0aGUgbmVlZCB0byByZXN0YXJ0IHRoZSBjb250YWlu ZXIuIEluIGEgY29uY3VycmVudCBwcm9kdWN0aW9uIGVudmlyb25tZW50LCB0aGlzIGNhbiBvYnZp b3VzbHkgY2F1c2UgYWxsIGtpbmRzIG9mIHNpZGUgZWZmZWN0cy4gU28gd2Ugd291bGQgbmVlZCB0 byB1c2UgYSBsaWZlY3ljbGUtYXdhcmUgcHJveHkgaGVyZSwgaW50ZXJjZXB0aW5nIGFuZCByZWdp c3RlcmluZyBhbGwgbWV0aG9kIGNhbGxzIHRvIHRoZSBiZWFuIGluc3RhbmNlLiBJbiBjYXNlIG9m IGFuIG9uZ29pbmcgcmVjb25maWd1cmF0aW9uLCB0aGUgY29udGFpbmVyIHdvdWxkIGhhdmUgdG8g d2FpdCBmb3IgYWxsIHJ1bm5pbmcgbWV0aG9kIGNhbGxzIHRvIHJldHVybiB3aGlsZSBibG9ja2lu ZyBhbGwgbmV3IHJlcXVlc3RzLCB0aGVuIGFwcGx5IHRoZSByZWNvbmZpZ3VyYXRpb24sIGFuZCBm aW5hbGx5IGFsbG93IHRoZSB3YWl0aW5nIHJlcXVlc3RzIHRvIHByb2NlZWQuDQogDQpUaGlzIHNv dW5kcyBsaWtlIGEgY2FzZSBmb3IgYW4gQU9QIGludGVyY2VwdG9yIHRvIG1lIQ0KDQoqIExvYWQv dW5sb2FkIGJlYW5zDQogDQpJIGd1ZXNzIHlvdSBtZWFuIGJlYW4gaW5zdGFuY2VzIGhlcmUsIG5v dCBiZWFuIGNsYXNzZXMsIGFuZCBJIGFzc3VtZSBsb2FkIC8gdW5sb2FkIG1lYW5zIGludm9raW5n IGluaXRpYWxpemUgLyBkaXNwb3NlIG9mIHByZWRlZmluZWQgYmVhbiBpbnN0YW5jZXMuIEkgd29u ZGVyIHdoYXQgdXNlIGNhc2VzIHlvdSBzZWUgZm9yIGV4cGxpY2l0IGJlYW5GYWN0b3J5LmxvYWQo Im15QmVhbk5hbWUiKSBhbmQgYmVhbkZhY3RvcnkudW5sb2FkKCJteUJlYW5OYW1lIikgY2FsbHMu IFdoZW4gd291bGQgYW4gYXBwbGljYXRpb24gZGV2ZWxvcGVyIHdhbnQgdG8gZXhwbGljaXRseSBs b2FkIGFuZCB1bmxvYWQgYmVhbnMgYXQgcnVudGltZSAtIG1heWJlIHRvIG1ha2UgY2VydGFpbiBl eHBvcnRlZCByZW1vdGUgc2VydmljZXMgYXZhaWxhYmxlIC8gdW5hdmFpbGFibGU/DQoNCiogUmVs b2FkIGJlYW4gY2xhc3MgKGluIGNvbWJpbmF0aW9uIHdpdGggYmVhbiBwb29scyB0aGlzIHByb2Jh Ymx5IG1lYW5zIHRoYXQgbXVsdGlwbGUgYmVhbiB2ZXJzaW9ucyB3aWxsIHJ1biBpbiBwYXJhbGxl bCBhdCB0aW1lcykNCiANCldlIHdvdWxkIG5lZWQgb3duIGNsYXNzbG9hZGVyIGhpZXJhcmNoaWVz IGZvciBzdWNoIHN0dWZmLiBCYXNpY2FsbHksIGV2ZXJ5IGJlYW4gaW5zdGFuY2Ugd291bGQgaGF2 ZSB0byBiZSBsb2FkZWQgaW4gaXRzIG93biBjbGFzc2xvYWRlciB0byBhY2hpZXZlIHRoaXMuIEkg cmF0aGVyIGNvbnNpZGVyIGNsYXNzbG9hZGVyIGhhbmRsaW5nIGFuIGlzc3VlIGZvciBKMkVFIGNv bnRhaW5lcnMsIG5vdCBmb3IgYXBwbGljYXRpb24gZnJhbWV3b3JrcywgZHVlIHRvIGFsbCB0aGUg bmFzdHkgaGFzc2xlcyB0aGF0IGFyZSBpbnZvbHZlZC4gQW5kIGFzIEkndmUgb3V0bGluZWQgYWJv dmUsIHRoaXMgaXMgcmVhbGx5IGhhcmQgaWYgbm90IGltcG9zc2libGUgdG8gaGFuZGxlIHByb3Bl cmx5IGluIGEgY29uY3VycmVudCBlbnZpcm9ubWVudCwgYXMgYW55IGJlYW4gY2FuIGhhdmUgZGVw ZW5kZW5jaWVzIG9uIGFueSBvdGhlci4gSG93IHRvIGd1YXJhbnRlZSBjb25zaXN0ZW5jeSB3aXRo aW4gdGhlIHdob2xlIHN5c3RlbSBoZXJlPw0KDQoqIFBlcnNpc3QgYmVhbiBjb25maWd1cmF0aW9u IChub3Qgc2VyaWFsaXphdGlvbiwgcHJvcGVydGllcyBvbmx5KQ0KIA0KV2h5IHdvdWxkIHlvdSB3 YW50IHRvIHBlcnNpc3QgYSBiZWFuJ3MgcHJvcGVydHkgdmFsdWVzIC0gd2hlbiB3b3VsZCB5b3Ug d2FudCB0byBsb2FkIHRoZW0gYWdhaW4/IEJhc2ljYWxseSwgdGhlIGJlYW4gZmFjdG9yeSBkZWZp bmVzIGFsbCBwcm9wZXJ0eSB2YWx1ZXMsIGUuZy4gaW4gYSBwcm9wZXJ0aWVzIG9yIFhNTCBmaWxl LiBDaGFuZ2luZyB2YWx1ZXMgYXQgcnVudGltZSBzaG91bGQgYWxzbyBvY2N1ciB2aWEgdGhlc2Ug ZmlsZXMgSU1PLCB0aGUgbW9kaWZpZWQgZmlsZSB0aW1lc3RhbXAgdHJpZ2dlcmluZyBhIHJlY29u ZmlndXJhdGlvbiBvZiB0aGUgd2F0Y2hpbmcgZmFjdG9yeS4NCg0KKiBGaW5hbGx5LCBhIGNvbnRh aW5lciBuZWVkcyB0byBiZSB3cml0dGVuIHdoaWNoIHdvdWxkIGFsbG93IGFjY2VzcyB0byBhbGwg YmVhbnMgYW5kIHRoZWlyIGNvbmZpZ3VyYXRpb24gZnJvbSB0aGUgb3V0c2lkZSwgcGx1cyBvcHRp b25zIHRvIGxvYWQvdW5sb2FkIGJlYW5zLCByZWNvbmZpZ3VyZSB0aGVtLCBpbnNwZWN0IHRoZW0g YW5kIHNvIG9uLg0KIA0KQmFzaWNhbGx5LCBhIFNwcmluZyBCZWFuRmFjdG9yeSByZXNwLiBBcHBs aWNhdGlvbkNvbnRleHQgbWF0Y2hlcyB0aGF0IHJvbGUsIGFsdGhvdWdoIHRoZXNlIGludGVyZmFj ZXMgcmVwcmVzZW50IGEgYmVhbiB1c2VyIEFQSSwgYXZvaWRpbmcgYmVhbiBkZWZpbml0aW9uIGRl dGFpbHMuIEltcGxlbWVudGF0aW9uIGNsYXNzZXMgbGlrZSBBYnN0cmFjdEJlYW5GYWN0b3J5LCBM aXN0YWJsZUJlYW5GYWN0b3J5SW1wbCwgYW5kIEFic3RyYWN0QXBwbGljYXRpb25Db250ZXh0IG9m ZmVyIGFjY2VzcyB0byBzdWNoIFNQSSBkZXRhaWxzIHRvby4gV2l0aCBzb21lIGFkZGVkIG1ldGhv ZHMgZS5nLiBmb3IgbG9hZGluZy91bmxvYWRpbmcsIHN1ZmZpY2llbnQgY29udHJvbCBhbmQgaW5z cGVjdGlvbiBjYXBhYmlsaXRpZXMgc2hvdWxkIGJlIGF2YWlsYWJsZS4NCiANClJlZ2FyZHMsDQpK dWVyZ2VuDQo= |
|
From: Rod J. <rod...@in...> - 2003-07-13 16:03:52
|
Ivan, Juergen
Some thoughts. Ivan, don't get the impression I'm negative about this area:
I just want to make sure that any additional complexity we build into the
bean factory is warranted.
> * Complete bean life cycle: parameters, initialisation, start, stop,
suspend, resume, reconfigure, dispose/destroy
> I agree that a single pair of start/stop methods should do the job, no
need for a suspend/resume. This could be modelled as a "Startable"
interface. A separate "Disposable" interface could feature a dispose method
for cleanup purposes on shutdown.
+1. Non-invasive in good Spring fashion. Only if a bean implements these
methods will they be called. No irrelevant methods to implement like
ejbActivate/ejbPassivate for SLSBs.
>
> * Beans that want to can execute on their own thread
> How is this supposed to work? The execution thread is always determined by
the caller of a bean's methods. In that respect, a bean can't execute "on
its own thread", if I understand correctly. A bean can *create* its own
threads though, either on initialization or on certain method calls. But in
any case, the main method invocation will always execute in the caller's
thread. Therefore I don't think that we need "own thread" support. Spring
simply treats such thread starters as conventional beans, initializing them
and making them available. It doesn't care if and when a bean starts and
stops new threads - that's the bean's responsibility.
You mean a bean that kicks off an asynchronous process somehow? But what
would it return to the caller? We probably do need more sophisticated thread
models for app context event listeners. At present the multicast event
listener uses the same thread as the call that created the event, allowing a
rogue listener to lock the app. It would be easy to support several options,
with this the default, as it's low overhead if people implement their
listeners properly. (Ie a listener kicks off a background thread if it needs
to).
> * Singleton/shared and not-shared beans
> * Bean pools (check-in, check-out)
>
> As you've noted, Spring already supports the first two notions. Regarding
bean pools, I'm not too convinced if they actually add value. In contrast to
EJBs, beans are extremely lightweight, the on-demand creation overhead
normally doesn't matter. Personally, I just use singleton beans, as I find
hardly any scenarios where I couldn't write a thread-safe, reusable bean.
Even when exporting remote beans via Hessian / Burlap / RMI / SOAP /
whatever, it should always be possible to write a single thread-safe bean
instance.
I agree on Juergen regarding pooling. IMHO, object pooling is overrated,
considering the efficiency of garbage collection in modern JVMs. With our
model, if people want single threaded, they can use the "prototype"
(non-shared) model. This will then be something like WebWork.
> Instance pooling would add a significant amount of overhead: There would
indeed have to be an explicit checkout and checkin, or a transparent
checkout / checkin on each method invocation, using an invocation proxy that
delegates to the actual pooled instance. That may make sense for access to
load-balanced remote services, but I really doubt the value for local
invocations. I simply don't see a need for modelling local services this
way, even if EJB's Stateless Session Beans offer such pooling for local
instances too.
Like Juergen, I'd need a lot of persuasion oin this.
> * Ability to safely reconfigure a bean that is referenced by other beans
> Reconfiguration is indeed an interesting issue, as it may need to block
the system to guarantee consistency: Various configuration changes might
depend on each other, i.e. need to be applied completely or not at all to
keep the system intact. This is somewhat similar to a classloader that
supports "hot" class reloading, like in a servlet container: Effectively, it
can't be guaranteed that updating a class won't break the system due to all
kinds of side effects. Thus, hot class reloading is mainly a development
feature, not recommended for production environments.
> For specific settings that are local to a single bean, "hot"
reconfiguration should be solvable though. For development environments, one
could simply overwrite the respective bean properties and proceed - this
would be fine in many cases, avoiding the need to restart the container. In
a concurrent production environment, this can obviously cause all kinds of
side effects. So we would need to use a lifecycle-aware proxy here,
intercepting and registering all method calls to the bean instance. In case
of an ongoing reconfiguration, the container would have to wait for all
running method calls to return while blocking all new requests, then apply
the reconfiguration, and finally allow the waiting requests to proceed.
> This sounds like a case for an AOP interceptor to me!
This is a very interesting area. Semi-coherent braindump follows.
Do we want to call additional setters on a running bean? e.g.
setRetryCount(n) to a new value? This might be appropriate in some cases,
especially for simpler things. Yet it would place constraints on beans,
implying that some metadata might be required to indicate which fields were
refreshable.
Our AOP, and your suggestions regarding interceptors, suggest the idea of
using copy-on-write in a proxy. However, this would only work with proxies,
and the synchronization could be scary. We could have as well as the simple
InvokerInterceptor (which invokes the target via reflection) a
ChangeAwareInvoker, that recognizes when it needs a new instance of the
underlying object or needs to reconfigure the underlying object, and queues
requests at that time. This would mean only a new interceptor not a major
change to the framework. It would have to know when things had changed,
however, so the BF would need to provide that. I guess the factory could
poll the underlying resource (the abstract factory could provide polling in
a storage-independent way). How would it communicate changes? Via setting
new property values on bean instances? We don't really want to detype the
changes into an update(Properties) method or the like.
How much blocking is required really depends on the app code in question.
Which means that metadata might need to be used to drive it.
>
> * Load/unload beans
>
> I guess you mean bean instances here, not bean classes, and I assume load
/ unload means invoking initialize / dispose of predefined bean instances. I
wonder what use cases you see for explicit beanFactory.load("myBeanName")
and beanFactory.unload("myBeanName") calls. When would an application
developer want to explicitly load and unload beans at runtime - maybe to
make certain exported remote services available / unavailable?
I'd like to see use cases for this.
>
> * Reload bean class (in combination with bean pools this probably means
that multiple bean versions will run in parallel at times)
> We would need own classloader hierarchies for such stuff. Basically, every
bean instance would have to be loaded in its own classloader to achieve
this. I rather consider classloader handling an issue for J2EE containers,
not for application frameworks, due to all the nasty hassles that are
involved. And as I've outlined above, this is really hard if not impossible
to handle properly in a concurrent environment, as any bean can have
dependencies on any other. How to guarantee consistency within the whole
system here?
I don't want to get into class loading, if we can possibly help it.
>
> * Persist bean configuration (not serialization, properties only)
Isn't the XML doing this?
> Why would you want to persist a bean's property values - when would you
want to load them again? Basically, the bean factory defines all property
values, e.g. in a properties or XML file. Changing values at runtime should
also occur via these files IMO, the modified file timestamp triggering a
reconfiguration of the watching factory.
That's my view. The factory should be able to compute the minimum change
set.
> * Finally, a container needs to be written which would allow access to all
beans and their configuration from the outside, plus options to load/unload
beans, reconfigure them, inspect them and so on.
> Basically, a Spring BeanFactory resp. ApplicationContext matches that
role, although these interfaces represent a bean user API, avoiding bean
definition details. Implementation classes like AbstractBeanFactory,
ListableBeanFactoryImpl, and AbstractApplicationContext offer access to such
SPI details too. With some added methods e.g. for loading/unloading,
sufficient control and inspection capabilities should be available.
What about JMX? So long as it could be done without forcing JMX complexity
on user code.
Regards,
Rod
|
|
From: Ivan R. <iv...@we...> - 2003-07-14 14:38:27
|
> You mean a bean that kicks off an asynchronous process somehow? But what > would it return to the caller? We probably do need more sophisticated thread > models for app context event listeners. At present the multicast event > listener uses the same thread as the call that created the event, allowing a > rogue listener to lock the app. It would be easy to support several options, > with this the default, as it's low overhead if people implement their > listeners properly. (Ie a listener kicks off a background thread if it needs > to). It sounds like something the framework needs, although I did not have a need for such functionality in my projects. > This is a very interesting area. Semi-coherent braindump follows. > > Do we want to call additional setters on a running bean? e.g. > setRetryCount(n) to a new value? This might be appropriate in some cases, > especially for simpler things. Yet it would place constraints on beans, > implying that some metadata might be required to indicate which fields were > refreshable. Metadata sounds too complex. I would go for a black&white approach. Either a bean is reconfigurable or not. Reconfiguration makes sense the most with service beans and I guess that those would be the ones that would expose themselves as reconfigurable. I have a fear that we can build this but that it would become too complex. The only simple solutions is the one when you explicitly check beans in and out, and there you can treat one cycle as a transaction. Idle beans are obviously safe to reconfigure. Or can we confine ourselves to only reconfigure service beans. For example: call stop, reconfigure, call start (or do it transparently, which is probably easier). >>* Reload bean class (in combination with bean pools this probably means > > that multiple bean versions will run in parallel at times) > >>We would need own classloader hierarchies for such stuff. Basically, every > > bean instance would have to be loaded in its own classloader to achieve > this. I rather consider classloader handling an issue for J2EE containers, > not for application frameworks, due to all the nasty hassles that are > involved. And as I've outlined above, this is really hard if not impossible > to handle properly in a concurrent environment, as any bean can have > dependencies on any other. How to guarantee consistency within the whole > system here? > > I don't want to get into class loading, if we can possibly help it. OK, let's forget about that for the moment. I am not too keen either. >>* Persist bean configuration (not serialization, properties only) > > Isn't the XML doing this? What do you mean? >>* Finally, a container needs to be written which would allow access to all > > beans and their configuration from the outside, plus options to load/unload > beans, reconfigure them, inspect them and so on. > >>Basically, a Spring BeanFactory resp. ApplicationContext matches that > > role, although these interfaces represent a bean user API, avoiding bean > definition details. Implementation classes like AbstractBeanFactory, > ListableBeanFactoryImpl, and AbstractApplicationContext offer access to such > SPI details too. With some added methods e.g. for loading/unloading, > sufficient control and inspection capabilities should be available. > > What about JMX? So long as it could be done without forcing JMX complexity > on user code. Now, JMX is a very interested technology. I did not want to mention it before to avoid getting lost in discussion and because I am still investingating it. From what I've seen so far it should be possible to add a JMX layer to Spring and transparently expose JavaBeans that form the application. Not all beans should be exposed, we could mark the ones we want in the configuration somehow. Most of the features I have mentioned here have their place in JMX and some of them would be required in order to fully support it. But I am still playing with the spec. and the reference implementation, and I haven't formed my final opinion about it. But even know it is obvious that JMX fits naturally to the existing Spring functionality. -- ModSecurity (http://www.modsecurity.org) [ Open source IDS for Web applications ] |
|
From: Ivan R. <iv...@we...> - 2003-07-14 14:38:28
|
Juergen & Rob,
Thank you for your thoughtful replies. I will try to answer all
your questions hopefully not missing anything :)
> * Beans that want to can execute on their own thread
>
> How is this supposed to work? The execution thread is always
> determined by the caller of a bean's methods. In that respect,
> a bean can't execute "on its own thread", if I understand correctly.
> A bean can *create* its own threads though, either on initialization
> or on certain method calls. But in any case, the main method invocation
> will always execute in the caller's thread. Therefore I don't think that
> we need "own thread" support. Spring simply treats such thread starters
> as conventional beans, initializing them and making them available. It
> doesn't care if and when a bean starts and stops new threads - that's
> the bean's responsibility.
There are two ways to do this. One is to call the onStart method
on a separate thread and just let it run. When I was writing my email
I was thinking about something like that but after reading your email
I don't like that approach anymore. I agree that it should be a bean's
responsibility to do whatever it needs to do, including starting its
own thread of execution (and stopping it on onStop).
> * Bean pools (check-in, check-out)
>
> As you've noted, Spring already supports the first two notions. Regarding
> bean pools, I'm not too convinced if they actually add value.
> In contrast to EJBs, beans are extremely lightweight, the on-demand
> creation overhead normally doesn't matter.
I agree in general, but there are some cases when pooling is necessary.
We all use it for database access. I need it for threads (can't think
of anything else). Bean pools can be realised in a non-intrusive manner.
For example, a bean pool can consist of a single interface provided
facilities to create beans on-demand exist.
> Instance pooling would add a significant amount of overhead: There
> would indeed have to be an explicit checkout and check in, or a
> transparent checkout / check in on each method invocation, using an
> invocation proxy that delegates to the actual pooled instance. That
> may make sense for access to load-balanced remote services, but I
I would go for the explicit check in/checkout. That is one more
interface for a bean to support, but only if it wants to. I think
this is consistent with Spring philosophy. And no changes to the
rest of the framework would be required.
> * Load/unload beans
>
> I guess you mean bean instances here, not bean classes
Right, bean instances.
> and I assume load / unload means invoking initialize / dispose
> of predefined bean instances. I wonder what use cases you see for
> explicit beanFactory.load("myBeanName") and beanFactory.unload("myBeanName")
> calls. When would an application developer want to explicitly load
> and unload beans at runtime - maybe to make certain exported remote
> services available / unavailable?
Exactly. For example:
1. If there is a bean that performs certain services for other beans
and it depends on some external resources. If those services
become unavailable I need to manually replace the bean with something
else. Or, I might need to load another bean pointing to a backup
resource on the network (I might have restored the database from the
dump, for example).
2. My server consists from a series of plugins/services, and at any
time I can load the ones I need. Sometimes I need something to
happen at which time I can load the plugin. The plugin then registers
a listener and starts to respond to application events (or it changes
the application workflow somehow).
3. It is needed for the bean pool :)
> * Persist bean configuration (not serialization, properties only)
>
> Why would you want to persist a bean's property values - when would
> you want to load them again? Basically, the bean factory defines all
> property values, e.g. in a properties or XML file. Changing values at
> runtime should also occur via these files IMO, the modified file timestamp
> triggering a reconfiguration of the watching factory.
You certainly don't want automatic reconfiguration as you won't
be able to guarantee consistency. How would I be able to change the
configuration programatically? Your approach would force me to understand
how each factory stores configuration and I am not interested in that.
I would like to be able to change a parameter and keep the parameter
the next time application wakes up. This is probably a job for JMX
(I'll mention it in my next email).
--
ModSecurity (http://www.modsecurity.org)
[ Open source IDS for Web applications ]
|
|
From: Ivan R. <iv...@we...> - 2003-07-12 16:35:26
|
> You are very welcome to join us and work on this! Rod and > me will be happy to provide you with details on the current > bean factory and application context concepts :-) That is great to hear. I've spent some time today playing with the framework to get a feel of what's possible. Here are my notes. There are many ideas/features mentioned here but not all are equally important. Personally I would start simply but adding the equivalent to start/stop/dispose methods as they will benefit the majority of those building standalone applications. Other features are nice, but not essential. ... Some background --------------- I've spent the last year or so dealing with a Java daemon application (a RADIUS server). As part of that project I've built a framework similar to what I describe below, but not as fancy. Well, I couldn't really call that a framework since there wasn't much time to design it upfront, but it works and it works well. This server consists of many components that are configured and wired at runtime from an XML-based configuration, just like the Spring framework. That was for work. After completing the project I decided to rebuild the framework from scratch for fun, so here I am. Requirements ------------ * Complete bean life cycle: parameters, initialisation, start, stop, suspend, resume, reconfigure, dispose/destroy. * Beans that want to can execute on their own thread * Singleton/shared and not-shared beans * Ability to safely reconfigure a bean that is referenced by other beans * Load/unload beans * Bean pools (check-in, check-out) * Reload bean class (in combination with bean pools this probably means that multiple bean versions will run in parallel at times) * Persist bean configuration (not serialization, properties only). Notes ----- At the moment Spring supports parameterization and initialization (with the InitializingBean interface). It would be simple to add one or more interfaces to support methods such as: start, stop, dispose/destroy (other names can be chosen to avoid clash with the Thread class). As an idea, beans implementing the Runnable interface could be launched as daemon threads. I am more against than for this idea (but you may think otherwise). I have also considered detecting a "main" method on an object and invoking it, simulating a command line. I am more against than for this idea (but you may think otherwise). We could have suspend/resume, or we can simply use start/stop for that purpose. I am not really sure. I lean toward using a single pair of methods, start and stop. Reconfiguring a bean is a bit more complicated. I was thinking about using proxies to intercept method invocations, wait until all method executions are completed, reconfigure the bean, and then resume. We would probably need to call stop/suspend before and start/resume after. The process with loading/unloading would be similar. Spring also supports singleton and not-shared beans at the moment. There is a space in between to support bean pools. I don't think that this can be supported transparently, there would have to exist a check in/checkout process. For example, a client bean would receive a reference to a bean pool and ask it for bean instances when required. When reconfiguring bean pools, there could be an option whether to only create new beans with new configuration (possibly removing all idle beans immediately) and let busy beans finish with their work, or reconfigure all bean instances. Finally, a container needs to be written which would allow access to all beans and their configuration from the outside, plus options to load/unload beans, reconfigure them, inspect them and so on. On a related note, I have also started work on a utility scripts that would allow tight integration of Java daemons with UNIX and Windows operating systems. Links ----- Some links to similar projects. I would say that they are all far more complicated than I would want. http://avalon.apache.org/framework/ http://www.picocontainer.org/ http://jakarta.apache.org/commons/sandbox/hivemind/ -- ModSecurity (http://www.modsecurity.org) [ Open source IDS for Web applications ] |
