Menu
▾
▴
springframework-developer
|
From: <jue...@we...> - 2003-11-01 16:07:09
|
Q2FtZXJvbiwNCiANCkdvb2QgcG9pbnRzLiBJJ3ZlIHJlcGVhdGVkbHkgY29uc2lkZXJlZCByZWxh eGluZyB0aGF0IFhNTCBpZCByZXF1aXJlbWVudCBteXNlbGYsIEJUVywgdG8gZWFzZSBCZWFuTmFt ZVVybEhhbmRsZXJNYXBwaW5nLW1hcHBlZCBjb250cm9sbGVycyBkZWZpbml0aW9ucyB3aXRoIFNw cmluZydzIHdlYiBNVkMuDQogDQpTbyBJJ3ZlIGp1c3QgaW1wbGVtZW50ZWQgdGhlIGZvbGxvd2lu ZyBjaGFuZ2VzOg0KIA0KLSBUaGVyZSdzIGEgQmVhbk5hbWVBd2FyZSBpbnRlcmZhY2Ugbm93LCB3 aXRoIGEgc2V0QmVhbk5hbWUgbWV0aG9kIHRoYXQgZ2V0cyBjYWxsZWQgb24gaW5pdGlhbGl6YXRp b24uIEJUVywgdGhlIEJlYW5GYWN0b3J5IGludGVyZmFjZSBjYWxscyB0aGUgY2Fub25pY2FsIG5h bWUgIm5hbWUiIGFuZCBhbGlhcyBuYW1lcyAiYWxpYXNlcyIsIHdoaWxlIHRoZSBYTUwgYmVhbiBk ZWZpbml0aW9uIGZvcm1hdCBhZG9wdHMgdGhlIFhNTCBzdHlsZSBvZiBhbiBpZCBhdHRyaWJ1dGUs IGFsbG93aW5nIGZvciBtdWx0aXBsZSBhbGlhc2VzIHZpYSBhIGRlbGltaXRlZCAibmFtZSIgYXR0 cmlidXRlLg0KIA0KLSBUaGUgImlkIiBhdHRyaWJ1dGUgaXMgbm8gbG9uZ2VyIHJlcXVpcmVkIGlu IHRoZSBYTUwgYmVhbiBkZWZpbml0aW9uIGZvcm1hdC4gSWYgbm8gaWQgaXMgc3BlY2lmaWVkLCB0 aGUgZmlyc3QgbmFtZSBpbiB0aGUgIm5hbWUiIGF0dHJpYnV0ZSB3aWxsIGJlIHVzZWQgYXMgY2Fu b25pY2FsIG5hbWUgKGFsbCBvdGhlcnMgYXMgYWxpYXNlcykuIElmIG5vIGlkIGFuZCBubyBuYW1l IHNwZWNpZmllZCwgYW4gZXhjZXB0aW9uIHdpbGwgZ2V0IHRocm93bi4gTm90ZSB0aGF0IHlvdSBu ZWVkIHRvIHVzZSB0aGUgZ2VuZXJpYyA8cmVmIGJlYW49Ii4uLi8+IHN5bnRheCB0byByZWZlcmVu Y2UgYW55IGJlYW4gbmFtZSwgYXMgdGhlIG1vcmUgcmVzdHJpY3RpdmUgPHJlZiBsb2NhbD0iLi4u Ii8+IHdpbGwgYmUgdmFsaWRhdGVkIGFnYWluc3QgbG9jYWwgWE1MIGlkcy4gSW4gZ2VuZXJhbCwg aWYgeW91IGRvbid0IG5lZWQgdG8gcmVseSBvbiBYTUwgaWQgdmFsaWRhdGlvbiwgYWx3YXlzIHVz ZSA8cmVmIGJlYW49Ii4uLiIvPi4NCiANCi0gU3ByaW5nIGFscmVhZHkgaGFkIGEgUHJvcGVydGll c0ZhY3RvcnlCZWFuIGNsYXNzIGZvciBtYWtpbmcgYSBwcm9wZXJ0aWVzIGZpbGUgaW4gdGhlIGNs YXNzIHBhdGggYXZhaWxhYmxlIGFzIFByb3BlcnRpZXMgYmVhbiBpbiB0aGUgYmVhbiBmYWN0b3J5 LiBJJ3ZlIHJld29ya2VkIHRoaXMgdG8gYWxzbyBzdXBwb3J0IGxvY2FsIHByb3BlcnRpZXMgdmlh IGEgInByb3BlcnRpZXMiIGJlYW4gcHJvcGVydHkgKHRvIGJlIGZpbGxlZCB2aWEgIjxwcm9wcz4i IGluIHRoZSBYTUwgY2FzZSkuIEl0IGNhbiBhbHNvIG1lcmdlIHByb3BlcnRpZXMgZnJvbSBhIGZp bGUgd2l0aCBsb2NhbGx5IGRlZmluZWQgb25lcy4gWW91IHNob3VsZCBiZSBhYmxlIHRvIHVzZSB0 aGF0IGluc3RlYWQgb2YgeW91ciBvd24gUHJvcGVydGllc0ZhY3RvcnlCZWFuIGltcGxlbWVudGF0 aW9uLiBUaGVyZSdzIGFsc28gYSBSZXNvdXJjZVByb3BlcnRpZXNGYWN0b3J5QmVhbiB0aGF0IGxv YWRzIGEgcHJvcGVydGllcyBmaWxlIGFzIGFwcGxpY2F0aW9uIGNvbnRleHQgcmVzb3VyY2UgKHZp YSBBcHBsaWNhdGlvbkNvbnRleHQuZ2V0UmVzb3VyY2VCeVBhdGgpLg0KIA0KSWYgbm9vbmUgb2Jq ZWN0cywgSSB3aWxsIGNvbW1pdCB0aGVzZSBjaGFuZ2VzIHRvIENWUyB0b21vcnJvdy4gSSBndWVz cyB0aGUgImlkIiByZWxheGF0aW9uIGlzIGRlYmF0YWJsZSwgYnV0IEknbSBzdHJvbmdseSBmb3Ig aXQgYXMgbXkgY29sbGVhZ3VlcyBhdCB3ZXJrM0FUIHRlbmQgdG8gdXNlIEJlYW5OYW1lVXJsSGFu ZGxlck1hcHBpbmcgYSBsb3QgYW5kIGhhdmUgcmVwZWF0ZWRseSBjb21wbGFpbmVkIGFib3V0IHRo ZSBuZWVkIGZvciBhbiBhZGRpdGlvbmFsIGlkIGF0dHJpYnV0ZS4gQ2FtZXJvbiBmYWNlcyBhIHNp bWlsYXIgdXNlIGNhc2UgZm9yIFdlYldvcmsgYWN0aW9uczsgd2Ugc2hvdWxkIGVhc2Ugc3VjaCBz dHVmZiwgZXZlbiBpZiBYTUwgaWRzIGFyZSBzdGlsbCByZWNvbW1lbmRlZCBmb3Igbm9ybWFsIGJl YW5zLg0KIA0KSnVlcmdlbg0KIA0KDQoJLS0tLS1VcnNwcsO8bmdsaWNoZSBOYWNocmljaHQtLS0t LSANCglWb246IENhbWVyb24gQnJhaWQgW21haWx0bzpjYW1lcm9uQGRhdGFjb2RleC5uZXRdIA0K CUdlc2VuZGV0OiBTYSAwMS4xMS4yMDAzIDEzOjIwIA0KCUFuOiBzcHJpbmdmcmFtZXdvcmstZGV2 ZWxvcGVyQGxpc3RzLnNvdXJjZWZvcmdlLm5ldCANCglDYzogDQoJQmV0cmVmZjogW1tXMy1TUEFN XV0gLSBbU3ByaW5nZnJhbWV3b3JrLWRldmVsb3Blcl0gQmVhbiBmYWN0b3J5IGdldHRpbmcgYWNj ZXNzIHRvIGl0cyBiZWFuIGlkIC0gRW1haWwgZm91bmQgaW4gc3ViamVjdA0KCQ0KCQ0KDQoJSXMg dGhlcmUgYW55IHdheSB0aGF0IEkgY2FuIGFsbG93IGEgYmVhbiBmYWN0b3J5IHRvIGZpbmQgb3V0 IGl0cyBpZA0KCWF0dHJpYnV0ZSBmcm9tIHRoZSBhcHBsaWNhdGlvbkNvbnRleHQueG1sDQoJDQoJ aS5lLiBJIGFtIHRyeWluZyB0byBnZXQgYSBncmlwIG9uIGhvdyBzcHJpbmcgd29ya3MsIGFuZCB0 aGVyZWZvcmUgSSBhbQ0KCXRyeWluZyB0byB3cml0ZSBhIGxpdHRsZSBpbnRlZ3JhdGlvbiBsYXll ciB0byBtYWtlIHNwcmluZyBhbiBhY3Rpb24NCglmYWN0b3J5IGZvciB4d29yaywgdG8gYWxsb3cg bWUgdG8gdXNlIHNwcmluZyBjb21wb25lbnRzIGFuZA0KCWludGVyY2VwdG9ycy4gIEkgd2FudCB0 byB0cnkgYW5kIGF2b2lkIHJlcGV0aXRpb24gb2YgY29uZmlndXJhdGlvbg0KCXdoZXJldmVyIHBv c3NpYmxlLg0KCQ0KCUkgaGF2ZSBpdCBhdCB0aGUgc3RhZ2Ugd2hlcmUgSSBoYXZlIGEgYmVhbiBk ZWNsYXJhdGlvbiBsaWtlIHRoaXMgOg0KCQ0KCSAgICA8YmVhbiBpZD0iZGVmYXVsdEFjdGlvblRy YW5zYWN0aW9uQXR0cmlidXRlcyINCgljbGFzcz0iY29tLmRhdGFjb2RleC5zcHJpbmcuYmVhbnMu UHJvcGVydGllc0ZhY3RvcnlCZWFuIj4NCgkgICAgICAgIDxwcm9wZXJ0eSBuYW1lPSJwcm9wZXJ0 aWVzIj4NCgkgICAgICAgICAgICA8cHJvcHM+DQoJICAgICAgICAgICAgICAgIDxwcm9wIGtleT0i ZXhlY3V0ZSI+UFJPUEFHQVRJT05fUkVRVUlSRUQ8L3Byb3A+DQoJICAgICAgICAgICAgPC9wcm9w cz4NCgkgICAgICAgIDwvcHJvcGVydHk+DQoJICAgIDwvYmVhbj4NCgkNCgkgICAgPGJlYW4gaWQ9 ImFkbWluLlNwcmluZ0FkbWluQWN0aW9uIiBjbGFzcz0iV2Vid29ya0FjdGlvbkZhY3RvcnlCZWFu Ij4NCgkgICAgICAgIDxwcm9wZXJ0eQ0KCW5hbWU9ImFjdGlvbiI+PHZhbHVlPi9hZG1pbi9TcHJp bmdBZG1pbkFjdGlvbjwvdmFsdWU+PC9wcm9wZXJ0eT4NCgkgICAgICAgIDxwcm9wZXJ0eSBuYW1l PSJ0cmFuc2FjdGlvbk1hbmFnZXIiPjxyZWYNCglsb2NhbD0idHJhbnNhY3Rpb25NYW5hZ2VyIi8+ PC9wcm9wZXJ0eT4NCgkgICAgICAgIDxwcm9wZXJ0eSBuYW1lPSJ0cmFuc2FjdGlvbkF0dHJpYnV0 ZXMiPjxyZWYNCglsb2NhbD0iZGVmYXVsdEFjdGlvblRyYW5zYWN0aW9uQXR0cmlidXRlcyIvPjwv cHJvcGVydHk+DQoJICAgIDwvYmVhbj4NCgkNCglJIHdvdWxkIGxpa2UgdG8gYmUgYWJsZSB0byBh Y2Nlc3MgdGhlIGlkPSJhZG1pbi5TcHJpbmdBZG1pbkFjdGlvbiIgdmFsdWUNCgkob3IgdGhlIGJl YW4gbmFtZSBhdHRyaWJ1dGUpIGZyb20gd2l0aGluIHRoZSBXZWJ3b3JrQWN0aW9uRmFjdG9yeUJl YW4NCgl0aGVyZWZvcmUgcmVtb3ZpbmcgdGhlIG5lZWQgdG8gaGF2ZSB0aGUgZXh0cmEgJ2FjdGlv bicgcHJvcGVydHkNCgk8cHJvcGVydHkgbmFtZT0iYWN0aW9uIj48dmFsdWU+L2FkbWluL1Nwcmlu Z0FkbWluQWN0aW9uPC92YWx1ZT48L3Byb3BlcnR5Pi4NCgkNCglJZGVhbHkgSSB3b3VsZCBsaWtl IHRvIHVzZSB0aGUgL2FkbWluL1NwcmluZ0FkbWluQWN0aW9uIGFzIHRoZSBiZWFuIGlkDQoJdG8g bWFrZSBtYXBwaW5nIGZyb20gV2ViV29yayBzZWFtbGVzcywgYW5kIHdpdGhvdXQgbmVlZGluZyB0 aGUNCgljb252ZXJzaW9uIHRvICcuJyBzdHlsZS4NCglUaGVyZWZvcmUgLSBpcyB0aGVyZSBhbnkg d2F5IHRoYXQgdGhlIGJlYW4gaWQgY2FuIGJlIGNoYW5nZWQgdG8gYWxsb3cNCglhbnkgdmFsaWQg eG1sIHN0cmluZyA/ICBDdXJyZW50bHkgSSBhbSByZWNlaXZpbmcgYW4gZXhjZXB0aW9uLCBmcm9t IHRoZQ0KCXhtbCB2YWxpZGF0b3IuICBDYW4gdGhlIGlkIGF0dHRyaWJ1ZXQgYmUgY2hhbmdlZCB0 byBiZSBhDQoJDQoJWzIyOjEyOjI5XUlORk8gW1htbEJlYW5GYWN0b3J5XSBMb2FkaW5nIFhtbEJl YW5GYWN0b3J5IGZyb20gSW5wdXRTdHJlYW0NCglbW1JlYWRTdHJlYW0gY29tLmNhdWNoby52ZnMu RmlsZVJlYWRTdHJlYW1AMTkwYTBkNl1dDQoJWzIyOjEyOjI5XUVSUk9SW0NvbnRleHRMb2FkZXJd IEZhaWxlZCB0byBpbml0aWFsaXplIGJlYW5zIGluIGFwcGxpY2F0aW9uDQoJY29udGV4dDogTGlu ZSA0NCBpbiBYTUwgZG9jdW1lbnQgaXMgaW52YWxpZDsgbmVzdGVkIGV4Y2VwdGlvbiBpczoNCgkg ICAgb3JnLnhtbC5zYXguU0FYUGFyc2VFeGNlcHRpb246IEF0dHJpYnV0ZSB2YWx1ZQ0KCSIvYWRt aW4vU3ByaW5nQWRtaW5BY3Rpb24iIG9mIHR5cGUgSUQgbXVzdCBiZSBhIG5hbWUuDQoJb3JnLnht bC5zYXguU0FYUGFyc2VFeGNlcHRpb246IEF0dHJpYnV0ZSB2YWx1ZQ0KCSIvYWRtaW4vU3ByaW5n QWRtaW5BY3Rpb24iIG9mIHR5cGUgSUQgbXVzdCBiZSBhIG5hbWUuDQoJICAgIGF0IG9yZy5hcGFj aGUueGVyY2VzLnBhcnNlcnMuRE9NUGFyc2VyLnBhcnNlKFVua25vd24gU291cmNlKQ0KCSAgICBh dCBvcmcuYXBhY2hlLnhlcmNlcy5qYXhwLkRvY3VtZW50QnVpbGRlckltcGwucGFyc2UoVW5rbm93 biBTb3VyY2UpDQoJICAgIGF0IGphdmF4LnhtbC5wYXJzZXJzLkRvY3VtZW50QnVpbGRlci5wYXJz ZShEb2N1bWVudEJ1aWxkZXIuamF2YTo3NikNCgkNCglUaGUgZHRkIHN0YXRlcyB0aGF0IGl0IG15 c3QgYmUgYSB2YWxpZCBYTUwgSUQsIGFuZCB0byB1c2UgdGhlIG9wdGlvbmFsDQoJbmFtZSBhdHRy aWJ1dGUgaWYgeW91IHdhbnQgYW4gaWxsZWdhbCBuYW1lLiAgVGhvdWdoIHRoaXMgd2lsbCByZXF1 aXJlDQoJdHdvIGlkZW50aWZ5ZXJzIGZvciB0aGUgYmVhbiwgd2hpY2ggSSB0aGluayBpcyBwb2lu dGxlc3MuICBEb2VzIHRoZSBJRA0KCWhhdmUgdG8gYmUgbWFuZGF0b3J5LiAgQ2FuJ3QgYSB2YWxp ZGF0aW9uIGJlIGltcGxlbWVudGVkIGluIGphdmEgdG8NCgljaGVjayB0aGF0IGF0bGVhc3QgdGhl IG5hbWUgb3IgdGhlIGlkIGlzIHN1cHBsaWVkID8gIFRoZW4gdGhlIHNhbWUgZm9yDQoJdGhlIDwh QVRUTElTVCByZWYgbG9jYWwgSURSRUYgI0lNUExJRUQ+ICB0aGlzIGNvdWxkIGJlIGEgQ0RBVEEg d2l0aCBqYXZhDQoJYmFzZWQgdmFsaWRhdGlvbi4NCgkNCglDaGVlcnMsDQoJDQoJQ2FtZXJvbg0K CQ0KCS0tDQoJQW55IGRhbW4gZm9vbCBjYW4gd3JpdGUgY29kZSB0aGF0IGEgY29tcHV0ZXIgY2Fu IHVuZGVyc3RhbmQuLi4NCglUaGUgdHJpY2sgaXMgdG8gd3JpdGUgY29kZSB0aGF0IGh1bWFucyBj YW4gdW5kZXJzdGFuZC4NCglbTWFydGluIEZvd2xlciBodHRwOi8vd3d3Lm1hcnRpbmZvd2xlci5j b20vZGlzdHJpYnV0ZWRDb21wdXRpbmcvcmVmYWN0b3JpbmcucGRmXQ0KCQ0KCQ0KCQ0KCQ0KCQ0K CS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0N CglUaGlzIFNGLm5ldCBlbWFpbCBpcyBzcG9uc29yZWQgYnk6IFNGLm5ldCBHaXZlYmFjayBQcm9n cmFtLg0KCURvZXMgU291cmNlRm9yZ2UubmV0IGhlbHAgeW91IGJlIG1vcmUgcHJvZHVjdGl2ZT8g IERvZXMgaXQNCgloZWxwIHlvdSBjcmVhdGUgYmV0dGVyIGNvZGU/ICAgU0hBUkUgVEhFIExPVkUs IGFuZCBoZWxwIHVzIGhlbHANCglZT1UhICBDbGljayBIZXJlOiBodHRwOi8vc291cmNlZm9yZ2Uu bmV0L2RvbmF0ZS8NCglfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KCVNwcmluZ2ZyYW1ld29yay1kZXZlbG9wZXIgbWFpbGluZyBsaXN0DQoJU3ByaW5nZnJh bWV3b3JrLWRldmVsb3BlckBsaXN0cy5zb3VyY2Vmb3JnZS5uZXQNCglodHRwczovL2xpc3RzLnNv dXJjZWZvcmdlLm5ldC9saXN0cy9saXN0aW5mby9zcHJpbmdmcmFtZXdvcmstZGV2ZWxvcGVyDQoJ DQoNCg== |
|
From: Rod J. <rod...@in...> - 2003-11-01 16:15:39
|
Sounds reasonable. Thanks Juergen. Please disregard my previous email... Regards, Rod ----- Original Message ----- From: "jürgen höller [werk3AT]" <jue...@we...> To: <spr...@li...> Sent: Saturday, November 01, 2003 4:05 PM Subject: Re: [Springframework-developer] Bean factory getting access to its bean id > Cameron, > > Good points. I've repeatedly considered relaxing that XML id requirement myself, BTW, to ease BeanNameUrlHandlerMapping-mapped controllers definitions with Spring's web MVC. > > So I've just implemented the following changes: > > - There's a BeanNameAware interface now, with a setBeanName method that gets called on initialization. BTW, the BeanFactory interface calls the canonical name "name" and alias names "aliases", while the XML bean definition format adopts the XML style of an id attribute, allowing for multiple aliases via a delimited "name" attribute. > > - The "id" attribute is no longer required in the XML bean definition format. If no id is specified, the first name in the "name" attribute will be used as canonical name (all others as aliases). If no id and no name specified, an exception will get thrown. Note that you need to use the generic <ref bean=".../> syntax to reference any bean name, as the more restrictive <ref local="..."/> will be validated against local XML ids. In general, if you don't need to rely on XML id validation, always use <ref bean="..."/>. > > - Spring already had a PropertiesFactoryBean class for making a properties file in the class path available as Properties bean in the bean factory. I've reworked this to also support local properties via a "properties" bean property (to be filled via "<props>" in the XML case). It can also merge properties from a file with locally defined ones. You should be able to use that instead of your own PropertiesFactoryBean implementation. There's also a ResourcePropertiesFactoryBean that loads a properties file as application context resource (via ApplicationContext.getResourceByPath). > > If noone objects, I will commit these changes to CVS tomorrow. I guess the "id" relaxation is debatable, but I'm strongly for it as my colleagues at werk3AT tend to use BeanNameUrlHandlerMapping a lot and have repeatedly complained about the need for an additional id attribute. Cameron faces a similar use case for WebWork actions; we should ease such stuff, even if XML ids are still recommended for normal beans. > > Juergen > > > -----Ursprüngliche Nachricht----- > Von: Cameron Braid [mailto:ca...@da...] > Gesendet: Sa 01.11.2003 13:20 > An: spr...@li... > Cc: > Betreff: [[W3-SPAM]] - [Springframework-developer] Bean factory getting access to its bean id - Email found in subject > > > > Is there any way that I can allow a bean factory to find out its id > attribute from the applicationContext.xml > > i.e. I am trying to get a grip on how spring works, and therefore I am > trying to write a little integration layer to make spring an action > factory for xwork, to allow me to use spring components and > interceptors. I want to try and avoid repetition of configuration > wherever possible. > > I have it at the stage where I have a bean declaration like this : > > <bean id="defaultActionTransactionAttributes" > class="com.datacodex.spring.beans.PropertiesFactoryBean"> > <property name="properties"> > <props> > <prop key="execute">PROPAGATION_REQUIRED</prop> > </props> > </property> > </bean> > > <bean id="admin.SpringAdminAction" class="WebworkActionFactoryBean"> > <property > name="action"><value>/admin/SpringAdminAction</value></property> > <property name="transactionManager"><ref > local="transactionManager"/></property> > <property name="transactionAttributes"><ref > local="defaultActionTransactionAttributes"/></property> > </bean> > > I would like to be able to access the id="admin.SpringAdminAction" value > (or the bean name attribute) from within the WebworkActionFactoryBean > therefore removing the need to have the extra 'action' property > <property name="action"><value>/admin/SpringAdminAction</value></property>. > > Idealy I would like to use the /admin/SpringAdminAction as the bean id > to make mapping from WebWork seamless, and without needing the > conversion to '.' style. > Therefore - is there any way that the bean id can be changed to allow > any valid xml string ? Currently I am receiving an exception, from the > xml validator. Can the id atttribuet be changed to be a > > [22:12:29]INFO [XmlBeanFactory] Loading XmlBeanFactory from InputStream > [[ReadStream com.caucho.vfs.FileReadStream@190a0d6]] > [22:12:29]ERROR[ContextLoader] Failed to initialize beans in application > context: Line 44 in XML document is invalid; nested exception is: > org.xml.sax.SAXParseException: Attribute value > "/admin/SpringAdminAction" of type ID must be a name. > org.xml.sax.SAXParseException: Attribute value > "/admin/SpringAdminAction" of type ID must be a name. > at org.apache.xerces.parsers.DOMParser.parse(Unknown Source) > at org.apache.xerces.jaxp.DocumentBuilderImpl.parse(Unknown Source) > at javax.xml.parsers.DocumentBuilder.parse(DocumentBuilder.java:76) > > The dtd states that it myst be a valid XML ID, and to use the optional > name attribute if you want an illegal name. Though this will require > two identifyers for the bean, which I think is pointless. Does the ID > have to be mandatory. Can't a validation be implemented in java to > check that atleast the name or the id is supplied ? Then the same for > the <!ATTLIST ref local IDREF #IMPLIED> this could be a CDATA with java > based validation. > > Cheers, > > Cameron > > -- > Any damn fool can write code that a computer can understand... > The trick is to write code that humans can understand. > [Martin Fowler http://www.martinfowler.com/distributedComputing/refactoring.pdf] > > > > > > ------------------------------------------------------- > This SF.net email is sponsored by: SF.net Giveback Program. > Does SourceForge.net help you be more productive? Does it > help you create better code? SHARE THE LOVE, and help us help > YOU! Click Here: http://sourceforge.net/donate/ > _______________________________________________ > Springframework-developer mailing list > Spr...@li... > https://lists.sourceforge.net/lists/listinfo/springframework-developer > > > NHum>xmjzyDPrqz{~{zzu~zqz~{z |
|
From: Cameron B. <ca...@da...> - 2003-11-02 03:13:58
|
Thanks .. see inline response. jürgen höller [werk3AT] wrote: >Cameron, > >Good points. I've repeatedly considered relaxing that XML id requirement myself, BTW, to ease BeanNameUrlHandlerMapping-mapped controllers definitions with Spring's web MVC. > >So I've just implemented the following changes: > >- There's a BeanNameAware interface now, with a setBeanName method that gets called on initialization. BTW, the BeanFactory interface calls the canonical name "name" and alias names "aliases", while the XML bean definition format adopts the XML style of an id attribute, allowing for multiple aliases via a delimited "name" attribute. > > > Sounds good. >- The "id" attribute is no longer required in the XML bean definition format. If no id is specified, the first name in the "name" attribute will be used as canonical name (all others as aliases). If no id and no name specified, an exception will get thrown. Note that you need to use the generic <ref bean=".../> syntax to reference any bean name, as the more restrictive <ref local="..."/> will be validated against local XML ids. In general, if you don't need to rely on XML id validation, always use <ref bean="..."/>. > > > Excellent. >- Spring already had a PropertiesFactoryBean class for making a properties file in the class path available as Properties bean in the bean factory. I've reworked this to also support local properties via a "properties" bean property (to be filled via "<props>" in the XML case). It can also merge properties from a file with locally defined ones. You should be able to use that instead of your own PropertiesFactoryBean implementation. There's also a ResourcePropertiesFactoryBean that loads a properties file as application context resource (via ApplicationContext.getResourceByPath). > > > Thanks, that is a better idea. >If noone objects, I will commit these changes to CVS tomorrow. I guess the "id" relaxation is debatable, but I'm strongly for it as my colleagues at werk3AT tend to use BeanNameUrlHandlerMapping a lot and have repeatedly complained about the need for an additional id attribute. Cameron faces a similar use case for WebWork actions; we should ease such stuff, even if XML ids are still recommended for normal beans. > > > I could live with it either way. Though I thaink that the ID should be optional since it isn't required in all cases. >Juergen > > > -----Ursprüngliche Nachricht----- > Von: Cameron Braid [mailto:ca...@da...] > Gesendet: Sa 01.11.2003 13:20 > An: spr...@li... > Cc: > Betreff: [[W3-SPAM]] - [Springframework-developer] Bean factory getting access to its bean id - Email found in subject > > > > Is there any way that I can allow a bean factory to find out its id > attribute from the applicationContext.xml > > i.e. I am trying to get a grip on how spring works, and therefore I am > trying to write a little integration layer to make spring an action > factory for xwork, to allow me to use spring components and > interceptors. I want to try and avoid repetition of configuration > wherever possible. > > I have it at the stage where I have a bean declaration like this : > > <bean id="defaultActionTransactionAttributes" > class="com.datacodex.spring.beans.PropertiesFactoryBean"> > <property name="properties"> > <props> > <prop key="execute">PROPAGATION_REQUIRED</prop> > </props> > </property> > </bean> > > <bean id="admin.SpringAdminAction" class="WebworkActionFactoryBean"> > <property > name="action"><value>/admin/SpringAdminAction</value></property> > <property name="transactionManager"><ref > local="transactionManager"/></property> > <property name="transactionAttributes"><ref > local="defaultActionTransactionAttributes"/></property> > </bean> > > I would like to be able to access the id="admin.SpringAdminAction" value > (or the bean name attribute) from within the WebworkActionFactoryBean > therefore removing the need to have the extra 'action' property > <property name="action"><value>/admin/SpringAdminAction</value></property>. > > Idealy I would like to use the /admin/SpringAdminAction as the bean id > to make mapping from WebWork seamless, and without needing the > conversion to '.' style. > Therefore - is there any way that the bean id can be changed to allow > any valid xml string ? Currently I am receiving an exception, from the > xml validator. Can the id atttribuet be changed to be a > > [22:12:29]INFO [XmlBeanFactory] Loading XmlBeanFactory from InputStream > [[ReadStream com.caucho.vfs.FileReadStream@190a0d6]] > [22:12:29]ERROR[ContextLoader] Failed to initialize beans in application > context: Line 44 in XML document is invalid; nested exception is: > org.xml.sax.SAXParseException: Attribute value > "/admin/SpringAdminAction" of type ID must be a name. > org.xml.sax.SAXParseException: Attribute value > "/admin/SpringAdminAction" of type ID must be a name. > at org.apache.xerces.parsers.DOMParser.parse(Unknown Source) > at org.apache.xerces.jaxp.DocumentBuilderImpl.parse(Unknown Source) > at javax.xml.parsers.DocumentBuilder.parse(DocumentBuilder.java:76) > > The dtd states that it myst be a valid XML ID, and to use the optional > name attribute if you want an illegal name. Though this will require > two identifyers for the bean, which I think is pointless. Does the ID > have to be mandatory. Can't a validation be implemented in java to > check that atleast the name or the id is supplied ? Then the same for > the <!ATTLIST ref local IDREF #IMPLIED> this could be a CDATA with java > based validation. > > Cheers, > > Cameron > > -- > Any damn fool can write code that a computer can understand... > The trick is to write code that humans can understand. > [Martin Fowler http://www.martinfowler.com/distributedComputing/refactoring.pdf] > > > > > > ------------------------------------------------------- > This SF.net email is sponsored by: SF.net Giveback Program. > Does SourceForge.net help you be more productive? Does it > help you create better code? SHARE THE LOVE, and help us help > YOU! Click Here: http://sourceforge.net/donate/ > _______________________________________________ > Springframework-developer mailing list > Spr...@li... > https://lists.sourceforge.net/lists/listinfo/springframework-developer > > >N?HY隊X???'???u??w?+?m?$>? ????????xZ+????*.m騭?k?ۜ?+?????^??????jכz?^?? y!?DD????݅?i??^??P)brAޭ?m??????q???z?ݢv?{?)?~??{ >+?ׯzZ)z???X??X??*k?x ????u?ޖ?^?X???(?? ~??zw???i????l???q???z???l?X??)ߣ?)?)?~??{ >+?ׯzZ)er== > -- Any damn fool can write code that a computer can understand... The trick is to write code that humans can understand. [Martin Fowler http://www.martinfowler.com/distributedComputing/refactoring.pdf] |
|
From: Cameron B. <ca...@da...> - 2003-11-05 11:59:07
|
I've just checkout this code.
The bean/@id attribute relaxing is fantastic thanks!
I can now use the Spring Framework as an Action Factory for
Xwork/WebWork with no duplcation of configuration, using spring to
define business related interceptors : components, transactions,
security and webwork to provide web/view oriented interceptors :
request-params, validation
xwork.xml snippet :
<package name="admin" namespace="/admin" extends="default">
<action name="update" class="com.project.AdminUpdateAction"
method="txUpdate">
<result name="redirect">read.action?id=${id}</result>
</action>
</package>
applicationContext.xml snippet :
<bean name="/admin/update"
class="com.datacodex.spring.webwork.WebworkActionFactoryBean">
<property name="sessionFactory"><ref
local="sessionFactory"/></property>
<property name="transactionManager"><ref
local="transactionManager"/></property>
<property name="transactionAttributes"><ref
local="defaultActionTransactionAttributes"/></property>
</bean>
very simple, neat and clean !
Thanks guys for your fantastic framework.
Cameron.
jürgen höller [werk3AT] wrote:
>Cameron,
>
>Good points. I've repeatedly considered relaxing that XML id requirement myself, BTW, to ease BeanNameUrlHandlerMapping-mapped controllers definitions with Spring's web MVC.
>
>So I've just implemented the following changes:
>
>- There's a BeanNameAware interface now, with a setBeanName method that gets called on initialization. BTW, the BeanFactory interface calls the canonical name "name" and alias names "aliases", while the XML bean definition format adopts the XML style of an id attribute, allowing for multiple aliases via a delimited "name" attribute.
>
>- The "id" attribute is no longer required in the XML bean definition format. If no id is specified, the first name in the "name" attribute will be used as canonical name (all others as aliases). If no id and no name specified, an exception will get thrown. Note that you need to use the generic <ref bean=".../> syntax to reference any bean name, as the more restrictive <ref local="..."/> will be validated against local XML ids. In general, if you don't need to rely on XML id validation, always use <ref bean="..."/>.
>
>- Spring already had a PropertiesFactoryBean class for making a properties file in the class path available as Properties bean in the bean factory. I've reworked this to also support local properties via a "properties" bean property (to be filled via "<props>" in the XML case). It can also merge properties from a file with locally defined ones. You should be able to use that instead of your own PropertiesFactoryBean implementation. There's also a ResourcePropertiesFactoryBean that loads a properties file as application context resource (via ApplicationContext.getResourceByPath).
>
>If noone objects, I will commit these changes to CVS tomorrow. I guess the "id" relaxation is debatable, but I'm strongly for it as my colleagues at werk3AT tend to use BeanNameUrlHandlerMapping a lot and have repeatedly complained about the need for an additional id attribute. Cameron faces a similar use case for WebWork actions; we should ease such stuff, even if XML ids are still recommended for normal beans.
>
>Juergen
>
>
> -----Ursprüngliche Nachricht-----
> Von: Cameron Braid [mailto:ca...@da...]
> Gesendet: Sa 01.11.2003 13:20
> An: spr...@li...
> Cc:
> Betreff: [[W3-SPAM]] - [Springframework-developer] Bean factory getting access to its bean id - Email found in subject
>
>
>
> Is there any way that I can allow a bean factory to find out its id
> attribute from the applicationContext.xml
>
> i.e. I am trying to get a grip on how spring works, and therefore I am
> trying to write a little integration layer to make spring an action
> factory for xwork, to allow me to use spring components and
> interceptors. I want to try and avoid repetition of configuration
> wherever possible.
>
> I have it at the stage where I have a bean declaration like this :
>
> <bean id="defaultActionTransactionAttributes"
> class="com.datacodex.spring.beans.PropertiesFactoryBean">
> <property name="properties">
> <props>
> <prop key="execute">PROPAGATION_REQUIRED</prop>
> </props>
> </property>
> </bean>
>
> <bean id="admin.SpringAdminAction" class="WebworkActionFactoryBean">
> <property
> name="action"><value>/admin/SpringAdminAction</value></property>
> <property name="transactionManager"><ref
> local="transactionManager"/></property>
> <property name="transactionAttributes"><ref
> local="defaultActionTransactionAttributes"/></property>
> </bean>
>
> I would like to be able to access the id="admin.SpringAdminAction" value
> (or the bean name attribute) from within the WebworkActionFactoryBean
> therefore removing the need to have the extra 'action' property
> <property name="action"><value>/admin/SpringAdminAction</value></property>.
>
> Idealy I would like to use the /admin/SpringAdminAction as the bean id
> to make mapping from WebWork seamless, and without needing the
> conversion to '.' style.
> Therefore - is there any way that the bean id can be changed to allow
> any valid xml string ? Currently I am receiving an exception, from the
> xml validator. Can the id atttribuet be changed to be a
>
> [22:12:29]INFO [XmlBeanFactory] Loading XmlBeanFactory from InputStream
> [[ReadStream com.caucho.vfs.FileReadStream@190a0d6]]
> [22:12:29]ERROR[ContextLoader] Failed to initialize beans in application
> context: Line 44 in XML document is invalid; nested exception is:
> org.xml.sax.SAXParseException: Attribute value
> "/admin/SpringAdminAction" of type ID must be a name.
> org.xml.sax.SAXParseException: Attribute value
> "/admin/SpringAdminAction" of type ID must be a name.
> at org.apache.xerces.parsers.DOMParser.parse(Unknown Source)
> at org.apache.xerces.jaxp.DocumentBuilderImpl.parse(Unknown Source)
> at javax.xml.parsers.DocumentBuilder.parse(DocumentBuilder.java:76)
>
> The dtd states that it myst be a valid XML ID, and to use the optional
> name attribute if you want an illegal name. Though this will require
> two identifyers for the bean, which I think is pointless. Does the ID
> have to be mandatory. Can't a validation be implemented in java to
> check that atleast the name or the id is supplied ? Then the same for
> the <!ATTLIST ref local IDREF #IMPLIED> this could be a CDATA with java
> based validation.
>
> Cheers,
>
> Cameron
>
> --
> Any damn fool can write code that a computer can understand...
> The trick is to write code that humans can understand.
> [Martin Fowler http://www.martinfowler.com/distributedComputing/refactoring.pdf]
>
>
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: SF.net Giveback Program.
> Does SourceForge.net help you be more productive? Does it
> help you create better code? SHARE THE LOVE, and help us help
> YOU! Click Here: http://sourceforge.net/donate/
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>N?HY隊X???'???u??w?+?m?$>? ????????xZ+????*.m騭?k?ۜ?+?????^??????jכz?^?? y!?DD????݅?i??^??P)brAޭ?m??????q???z?ݢv?{?)?~??{
>+?ׯzZ)z???X??X??*k?x ????u?ޖ?^?X???(?? ~??zw???i????l???q???z???l?X??)ߣ?)?)?~??{
>+?ׯzZ)er==
>
--
Any damn fool can write code that a computer can understand...
The trick is to write code that humans can understand.
[Martin Fowler http://www.martinfowler.com/distributedComputing/refactoring.pdf]
|
