Hi Abraham,
Are you able to use the SCA Spring support to do what you need now?
- we fixed up the SCA Spring schema so that it is publicly available at
http://www.osoa.org/xmlns/sca/1.0/spring-sca.xsd
- a simple schemaLocation setting enables it to be found
We also checked out a method to access the Spring Context from within a Spring Bean running inside
SCA - and built a testcase which is available as part of the tests for the Spring Implementation
code. It's called SpringContextAccessTestCase and its one of the itests attached to the
implementation.spring module in Tuscany.
A snippet of the Spring Bean that is part of the test shows the method we use
to access the context:
public class TestContextAccessBean implements HelloWorld,
ApplicationContextAware {
private static ApplicationContext ctx;
static String hello = "Hello ";
// Return the hello string only if the application context is successfully
accessed
public String sayHello(String message) {
System.out.println("TestContextAccessBean - sayHello called");
ApplicationContext theContext = getApplicationContext();
if( theContext == null ) return null;
// A simple check to see if the context contains this bean,
which it should...
if ( !theContext.containsBean( "testBean" ) ) return null;
return (hello + message);
} // end sayHello()
/**
* Application context setter
*/
public void setApplicationContext(ApplicationContext appContext) throws
BeansException {
// Wiring the ApplicationContext into a static method
ctx = appContext;
}
/**
* Application context getter
* @return
*/
public static ApplicationContext getApplicationContext() {
return ctx;
}
... note the "ApplicationContextAware" interface, with its getter and setter methods for the
application context.
Hope that this helps,
Yours, Mike.
Abraham Washington wrote:
hi Ramkumar/Simon....yes, simon is correct in his assumption. depending
on the information passed into an operation, i need to set a couple
properties on a bean (at runtime obviously). as of right now, the i
added the bean to the service and change the properties. but, my
preferred way (this is just my design) would be to not add the bean and
use aop to grab the bean from the context and set the properties on the
necessary operations.
but, simon is right. in some instances properties need to be set on a
bean and thus we'd need to be able to grab it.
sorry didn't get back sooner. had a personal issue and then was out of
town...thx abe
----- Original Message ----
From: Simon Laws <[EMAIL PROTECTED]>
To: [email protected]
Sent: Monday, September 8, 2008 5:19:29 AM
Subject: Re: sca namespace in spring
On Mon, Sep 8, 2008 at 12:05 PM, Ramkumar R <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>> wrote:
Hi Abraham,
I have few corrections to my previous comments. Please see my
comments inline with my previous comments.
On Thu, Sep 4, 2008 at 11:03 PM, Ramkumar R <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>> wrote:
Hi Abraham,
Here I have few findings and suggestions for the spring
namespace and application Context issues.
*For Spring Namespace Issue:*
As per my earlier comments, the custom XML tags like
<sca:service>, <sca:reference> and <sca:property> and the sca
namespace will be supported only when Tuscany creates the
application context for you.
The reason is Tuscany not only defines the bean definition for
these tags, but also defines the logic. So I believe Tuscany
does the right thing to handle the sca namespace.
A detailed article on how you would go about writing your own
custom XML bean definition parsers and integrating such parsers
into the Spring IoC container can be found here....
http://static.springframework.org/spring/docs/2.5.x/reference/extensible-xml.html
*Loading Application Context using ClassPathXmlApplicationContext:*
Defining a bean as shown below,
<bean id="beanRefFactory"
class="org.springframework.context.support.ClassPathXmlApplicationContext">
<constructor-arg><list>
<value>Organization-spring-context.xml</value>
</list></constructor-arg>
</bean>
would also result in a namespace issue being thrown, as in this
case an application context is being created using
ClassPathXmlApplicationContext (which is not aware of the sca
namespace handlers).
Using the ClassPathXmlApplicationContext as shown above will not
throw namespace anymore. Identified that the namespace handler
registration had some issue with Tuscany and its now been fixed as
part of TUSCANY-2573.
As part of this fix, now the SCA namespace handlers are made aware
to the Spring Container as a whole, these namespaces will be ignored
by the application context other than SCAApplicationContext.
But still using ClassPathXmlApplicationContext does not provide the
required results when used with Tuscany as this application context
created ignores the <sca:service>, <sca:reference> and
<sca:property> beans.
Your comments to my below question would help to understand the
scanario better.
Here I have a question to ask, may be I am not good at spring,
basically I am trying to understand what is the special purpose
for using the ClassPathXmlApplicationContext to load the
Organization-spring-context.xml file, while by default Tuscany
would create the application context for this file when its been
specified as
<implementation.spring
location="Organization-spring-context.xml"/> in the composite file?
Your Comments on this would help us to come up with a better
solution.
*Accessing the Application Context:*
Trying to load an application context using the code shown below,
ApplicationContext applicationContext = (ApplicationContext)
ContextSingletonBeanFactoryLocator.getInstance("beanRefFactory.xml").useBeanFactory("beanRefFactory").getFactory();
to access the beans would also result in a namespace issue for
the same reason shown above.
I believe there is a workaround to this problem, which
demostrates how the runtime instance of the application context
can be accessed and also get access to the beans as shown here.....
http://blog.jdevelop.eu/2008/07/06/access-the-spring-applicationcontext-from-everywhere-in-your-application/
This solution returns the SCAApplicationContext instance which
resolves the namespace for you. Probably, you need to evaluate
if this workaround helps your scenario.
Please provide us with your feedback on the same and let me know
if I am missing something in this whole discussion.
--
Thanks & Regards,
Ramkumar Ramalingam
So what you are saying here Ram is that you can now read an SCA
annotated application context using the standard Spring APIs. The
context file will be read successfully but that the SCA annotations will
be ignored. Sounds right to me.
We do need to understand better Abraham's point about reading the
application context in order to set other bean properties. I'm assuming
that when he reads the application context from within the component
implementation bean he's expecting to get hold of the context that SCA
read originally so the fact that the context has SCA annotations in it
is not so relevant. The objective is just to go in and set properties on
beans and not re-start the appliation.
Regards
Simon
