hi Ramkumar... 1. The userName/passwords are encrypted and passed to the operation on the spring bean. so, no, the values are set after the spring application context is deployed. 2. I'm not too familar with policies, so i'm not sure how that will work. if you can point me down the right path, that's beneficial. it may be a backdoor from sca's perspective. i'll have to think more about that. but, our company uses spring/hibernate extensively and we can grab the context as needed. for cases like this, it's helpful. maybe sca/spring is not a good fit. our company is evaluation soa technologies and we are committed to spring/hibernate. thx abe
----- Original Message ---- From: Ramkumar R <[EMAIL PROTECTED]> To: [email protected] Sent: Tuesday, August 26, 2008 6:24:25 AM Subject: Re: sca namespace in spring Hi Abraham, Thanks for sharing the same, few question comes to my mind after looking at your scenario, when i look things from the SCA perspective..... 1. Are you looking to update the dataSource values (userName/password), just before the spring application context is deployed into the SCA domain. In such cases, would it not be possible to set the dataSource values (userName/password) using the component property being set in the composite? 2. In case, if you feel that these values are non-functional properties. how about applying policies for the spring components? For me accessing the application context from the runtime (as you have requested) after its been deployed in the SCA domain looks like a backdoor entry to the component deployed as services. Not sure if the SCA specs supports this. Will check on this one and get back to you. -- Thanks & Regards, Ramkumar Ramalingam
