I've managed to get a simple Spring client web app going under
samples/sca/spring. This involved work on the web app launcher as
well as the Spring impl. Right now the sample just references a bean
in the Spring context. Mvn will build a war and you can drop it into
a Servlet container (I've been using Jetty) as is since all
dependencies are bundled during build.
Moving forward, I'd like the sample to show remote wiring to another
service from the Spring client using Celtix. I was thinking the
structure would be something like this:
Application Root Component
|
Application Composite Component (default.scdl)
|
|---Spring Composite (application-context.xml)
|---SCA Reference using Celtix specified in the Spring component
entry
The web application currently sets the Spring Composite as the
"current SCA composite" for code in the web app that calls
CompositeContext.locateService(), for example in test.jsp The SCA
Spring composite is just a thin wrapper for the Spring application
context.
There are a couple of limitations with what I checked in. One is that
Spring APIs cannot be accessed from web app or application code since
Spring is loaded in a child application classloader along with other
extensions. The other is that the web application uses SCA APIs such
as locateService(). I'd prefer that the model at this level remain
Spring such that a developer writes their beans and web application
using all Spring APIs but deploys them along with an SCA SCDL file
which does all of the remote wiring. This way, the programming model
has not changed at all from Spring and SCA just (literally) adds
features to it by packaging some SCDLs and libraries with the war .
In order to do this, I think we are going to need to figure out a
classloading/packaging mechanism for SCA extensions that will allow
us to reference Spring APIs from the web app classloader (I'd prefer
not to do this by just packaging in the war and instead possibly have
the SCA runtime smart enough to load the Spring classes into the web
app classloader since this is a general problem with extensions in
any host environment).
In any event, I wanted to give Andy a heads up when he gets back
Monday. One of the big changes has been the new build structure (/sca
can now be built autonomously, as well as samples/sca). Another thing
is I had to put some hacks to get Spring working properly. One big
one was that the Spring application context gets loaded to introspect
the component type information and then needs to be refreshed when
the SCA context is set as a parent. Besides being suboptimal, I think
this will break eager instantiated singletons that take an SCA
reference since the first load will create them with the SCA context
being ready. Perhaps we could look for a better way to handle this,
potentially by being able to load a Spring configuration, introspect
it, and then tell the BeanFactory to initialize? Also, I don't think
<sca:service> and <sca:reference> are set up properly yet. One other
thing that I had to do is in the web app I placed the application-
context.xml in WEB-INF/classes so it can be picked up through
getResource() - perhaps we should have something more flexible.
Jim
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
