jmarino: so Raymond, I checked in some skeletal code last night
[11:15am] rfeng: yes, I did a brief reading
[11:16am] jmarino: k good .did you also have a chance to take a look
at the Groovy extension?
[11:16am] rfeng: so the basic idea is to model a set of spring beans
as a composite?
[11:16am] rfeng: yes
[11:16am] ant_away is now known as ant_.
[11:16am] jmarino: yes....
[11:16am] jmarino: the spring beans will be in a composite
[11:17am] jmarino: Spring 2 has a namespace handler as well...
[11:17am] rfeng: Can a SCA component wire to a spring bean in the
composite?
[11:17am] jmarino: this can be used to notify the SCA runtime to
prepare a service or reference3
[11:17am] rfeng: yes, I added that support in the 2nd patch
[11:17am] jmarino: reference
[11:17am] jmarino: how does it work?
[11:18am] jmarino: no an SCA component cannot wire directly to a
bean.. that would violate SCA....
[11:18am] rfeng: basically, similar as our StaxElementLoader +
ObjectFactory
[11:18am] jmarino: can you walk me through that first?
[11:18am] rfeng: sure
[11:18am] jmarino: we can come back to the wiring question in a sec
[11:19am] rfeng: ok, let's look at this bean def:
[11:19am] rfeng: <bean id="helloWorld1"
class="helloworld.SpringHelloWorldImpl">
[11:19am] rfeng: <property name="name">
[11:19am] rfeng: <value>World</value>
[11:19am] rfeng: </property>
[11:19am] rfeng: </bean>
[11:19am] rfeng: <tuscany:service id="helloWorld"
name="JavaHelloWorldComponent" />
[11:19am] rfeng: the 2nd one will be handled by a tuscany namespace
handler
[11:20am] jmarino: so what happens?
[11:21am] rfeng: the registration is done by contributing to META-INF/
spring.handlers, spring.schemas
[11:21am] rfeng: when somebody call beanFactory.getBean(id)
[11:22am] rfeng: the namespace handler will be invoked to provide a
bean def which can be the bean itself or a factory bean
[11:22am] jmarino: why is SCA involved at this stage?
[11:22am] rfeng: in this case, we allow Spring to call SCA services
using its own PM
[11:22am] jmarino: I assume they look up "helloWorld1"?
[11:23am] rfeng: maybe we're looking into different aspects
[11:23am] jmarino: "service" is entryPoint for me
[11:23am] jmarino: that may be the problem
[11:24am] jmarino: a "reference" is an external service
[11:24am] jmarino: so let's take another example....
[11:24am] rfeng: ok, let's do this way
[11:24am] jmarino: I have a foo Spring bean....
[11:24am] rfeng: 1) SCA talks to Spring
[11:24am] rfeng: 2) Spring talks to SCA
[11:24am] jmarino: yes so we are starting with 2
[11:25am] rfeng: ok
[11:25am] jmarino: so I have a foo bean...
[11:25am] jmarino: that is "wired" in spring to a reference (external
service)
[11:25am] rfeng: ok
[11:25am] jmarino: when I do getBean("foo") *Spring* returns the foo
bean
[11:25am] jmarino: in the process, it needs to resolve the reference
[11:25am] jmarino: to "bar"
[11:25am] rfeng: say foo requires bar (ref)
[11:25am] jmarino: yes
[11:26am] jmarino: at that point the spring context needs to talk to
something to get bar
[11:26am] rfeng: and bar is a SCA service
[11:26am] jmarino: bar is an SCA "reference" that may be wired to
something....
[11:26am] jmarino: it is opaque to Spring
[11:26am] rfeng: sure
[11:27am] jmarino: there is an SCA composite that needs to return the
reference
[11:27am] jmarino: Spring sees this composite as a hierarchical
application context
[11:27am] jmarino: Spring delegates to it to get the bar reference
[11:27am] rfeng: so in spring, foo --> bar, let's assume wire by id
[11:28am] rfeng: it will try to resolve the ref by calling
context.getBean("bar")
[11:28am] jmarino: what is calling context.getBean("bar")?
[11:29am] rfeng: Spring, calling appContext.getBean("bar"), right?
[11:29am] jmarino: internally maybe that is how it does the
resolution (at some point it does do that)
[11:29am] jmarino: but we don't need to worry about that
[11:30am] jmarino: the Spring app context....
[11:30am] jmarino: foo is in will have a parent app context...
[11:30am] jmarino: set by SCA...
[11:30am] jmarino: that app context will be responsibly for returning
"bar"
[11:30am] jmarino: the app context is actually the SCA composite
[11:30am] rfeng: I have a slight different view
[11:31am] jmarino: k shoot
[11:31am] rfeng: I thought the context is the regular spring context
[11:31am] jmarino: what is bar, another bean?
[11:31am] rfeng: and by using the extensible XML config, modeling bar
as another bean
[11:31am] rfeng: with the SCA ns
[11:32am] rfeng: I'm open, just try to understand your view
[11:32am] jmarino: yes I've seen that approach but I'm not sure
that's what we want....
[11:32am] jmarino: that bean will then have to resolve out to SCA anyway
[11:32am] rfeng: right
[11:33am] jmarino: I don't think we need two things (one in Spring,
one in SCA)
[11:33am] rfeng: ok
[11:33am] jmarino: makes changing things tricky...
[11:33am] jmarino: also I want to do something a bit different...
[11:33am] rfeng: sure
[11:33am] jmarino: I want to go from the Spring AOP chain *directly*
to the SCA Tuscany chain with no proxies
[11:34am] rfeng: ok, so we may intercept the Spring
[11:34am] jmarino: I haven't looked at this closely yet so I'm not
sure on the specifics
[11:34am] rfeng: and route to SCA?
[11:34am] rfeng: ok
[11:34am] jmarino: what do you mean by "intercept"
[11:34am] rfeng: apply advice
[11:35am] rfeng: let's continue with the foo/bar case
[11:35am] jmarino: k
[11:35am] rfeng: so by some means, we resolve foo's reference bar
[11:36am] jmarino: yes
[11:36am] rfeng: bar is fulfilled by SCA
[11:36am] jmarino: yep
[11:37am] rfeng: so a proxy (or ?) for bar will be injected into foo
[11:37am] jmarino: a *Spring* proxy will
[11:37am] rfeng: ok
[11:38am] rfeng: then let's say in the foo bean impl, calling
bar.doSomething(args)
[11:38am] jmarino: yes
[11:38am] rfeng: what will happen in your AOP thinking?
[11:39am] jmarino: that gets run down Spring's AOP chain (it's just a
bunch of interceptors)...
[11:39am] rfeng: yes
[11:39am] jmarino: at the end there is a TargetSource (I looked at
this about a year ago but I think it is mostly valid)....
[11:39am] rfeng: ok
[11:39am] jmarino: the target source will have a ref to the Tuscany
head interceptor...
[11:39am] jmarino: on the reference...
[11:40am] rfeng: ok
[11:40am] jmarino: that will then pass things down the Tuscany chain
[11:40am] rfeng: ok
[11:40am] jmarino: at the end there will be a TargetInvoker....
[11:40am] rfeng: ok
[11:40am] jmarino: that will dispatch to whatever is on the end of
the reference
[11:40am] rfeng: so this way, we can avoid the locateService ...
[11:40am] jmarino: how does locateService play into this?
[11:40am] rfeng: and glue the two chains together seamlessly
[11:41am] jmarino: yea I'd like to have the chains tied directly
[11:42am] jmarino: this may not be possible in all cases though
[11:42am] jmarino: in which case the proxy injected on bar...
[11:42am] jmarino: is just an SCA proxy
[11:42am] rfeng: ok
[11:43am] jmarino: this may require some things in Spring. I have a
bunch of questions out to Adrian Coyler on this...
[11:43am] jmarino: he hasn't responded yet but may be travelling
[11:43am] rfeng: ok
[11:43am] jmarino: the namespace handler comes into this as well...
[11:44am] jmarino: that is a callback into SCA to create the reference
[11:44am] jmarino: make sense?
[11:44am] rfeng: yes, that''s what I tried, binding a spring bean to
a SCA service
[11:45am] jmarino: so in the code I checked in it basically jams an
SCA proxy on the spring bean...I'd like to do the chain integration
[11:45am] rfeng: sure
[11:45am] haleh joined the chat room.
[11:45am] jmarino: do you want to talk about the other case now?
[11:45am] rfeng: sure
[11:45am] jmarino: service--->spring
[11:45am] rfeng: yes
[11:46am] jmarino: so let's say we have bar--->foo
[11:46am] jmarino: we do the same thing basically
[11:46am] rfeng: bar is SCA and foo is Spring
[11:46am] jmarino: yep
[11:46am] jmarino: bar is just an invocation chain
[11:46am] jmarino: there is a targetinvoker that looks up the Spring
bean and dispatches
[11:46am] rfeng: what would the composite look like?
[11:47am] jmarino: there is one wrinkle here
[11:47am] jmarino: XML?
[11:47am] rfeng: no, the artifacts
[11:47am] jmarino: runtime?
[11:47am] rfeng: let me put this way
[11:47am] rfeng: We model the spring beans as a composite
[11:48am] jmarino: I don't think we need to know anything about the
spring beans
[11:48am] jmarino: we just need a service with a target uri
[11:48am] jmarino: maybe I'm missing something?
[11:48am] rfeng: yes, so the URI points to "beans.xml"?
[11:48am] jmarino: no...
[11:49am] rfeng: ok, so what does it look like?
[11:49am] jmarino: the service definition is in the spring file (it
can also be in SCDL but let's ignore that for now)...
[11:49am] rfeng: ok
[11:49am] jmarino: the service definition contains a wire to the bean
[11:49am] rfeng: ok
[11:49am] jmarino: SCA somehow is made "aware" of the service....
[11:49am] jmarino: it then creates a ServiceContext....
[11:50am] rfeng: ok
[11:50am] jmarino: which is just a shell around a wire chain....
[11:50am] jmarino: the wire chain has a TargetInvoker per operation
[11:50am] rfeng: ok
[11:50am] jmarino: that invoker has a ref to the Spring app context...
[11:50am] rfeng: yes
[11:50am] jmarino: when it needs to dispatch it looks up the bean and
does it's thing.....(it may cache, etc.)...
[11:50am] rfeng: as well as the id for the bean?
[11:50am] jmarino: yes
[11:51am] rfeng: ok
[11:51am] jmarino: what I'd like to do....
[11:51am] jmarino: is not look up the bean if it is proxied....
[11:51am] rfeng: ok
[11:51am] jmarino: Spring sometimes does not proxy in which case we
need to do a reflective invoke....
[11:51am] jmarino: in the case where it is proxied,....
[11:51am] rfeng: but add the spring chain to SCA
[11:51am] jmarino: I want to just get the AOP chain back and send it
down to it
[11:51am] jmarino: yes
[11:52am] rfeng: ok, got it
[11:52am] rfeng: I was more on the non-proxy case
[11:52am] jmarino: the service context is managed by the SCa
composite "shell"
[11:52am] rfeng: ok
[11:52am] jmarino: yea that's pretty straightforward reflection. We
can however, precompute a lot of that upfront
[11:53am] jmarino: we don't need to do reflection on every invoke
[11:53am] rfeng: right
[11:53am] jmarino: of course all of this may be completely wrong
[11:53am] jmarino: it's just the way I would start
[11:53am] rfeng: it depends on how open spring is
[11:53am] jmarino: there are some other things we need from Spring.....
[11:54am] jmarino: for example, we need a way to load an app context
and then init it....
[11:54am] jmarino: for example, if I have a singleton....
[11:54am] jmarino: that is wired to a reference...
[11:54am] rfeng: ok
[11:54am] jmarino: it may get initialized before the SCA container
has had a chance to do its thing
[11:54am] jmarino: there may be some lazy loading stuff we can do.
[11:55am] jmarino: That's one of the questions I asked Adrian
[11:55am] jmarino: btw Adrian was an ex-IBMer now with Spring
[11:55am] jmarino: Spring is fairly open
[11:55am] rfeng: yes, I guess I met him before
[11:55am] jmarino: I think we just need to be careful about what we
do with it since we need to support a variety of things
[11:55am] jmarino: yea he's a super nice guy
[11:56am] jmarino: does this make sense to you or does it sound like
I'm smoking crack?
[11:56am] ant_: are you guys planning on posting this log to the
mailing list?
[11:56am] cr22rc: I think you're all high
[11:56am] rfeng: so the link of the chains will be handled by the SCA
spring container, right?
[11:56am] jmarino: yea
[11:56am] jmarino: to the post, not to smoking crack
[11:57am] rfeng:
[11:57am] jmarino: yes chains will be handled by SCA
[11:57am] cr22rc: california guys are so lose
[11:57am] jmarino: yea not that loose though
[11:57am] rfeng: BTW, one thing I'm not clear is how the composite
looks like
[11:57am] jmarino: I figured the crack ref would get people interested
[11:57am] jmarino: the xML?
[11:58am] rfeng: say we have a bunch of beans from spring in the same
app context
[11:58am] rfeng: b1, b2, ..., bn
[11:59am] rfeng: so from the SCA point of view, we just have a
composite (with all the spring beans in the same context)?
[11:59am] jmarino: this is an interesting question...let's take the
simple case first....
[11:59am] jmarino: I see a two tier approach...
[11:59am] jmarino: there is a Spring app context which contains all
the beans...
[11:59am] jmarino: that app context is contained in an SCA composite
[12:00pm] rfeng: ok
[12:00pm] jmarino: the SCA composite holds on to ReferenceContexts
and ServiceContexts
[12:00pm] rfeng: ok
[12:00pm] jmarino: Spring doesn't have those things
[12:00pm] rfeng: right
[12:00pm] jmarino: now it's interesting to see what happens if we
have a partial composite
[12:00pm] jmarino: we don't have this in the spec yet....
[12:00pm] rfeng: ok
[12:01pm] jmarino: but I may have some SCA components as well
[12:01pm] jmarino: in that case, they would be in the SCA shell
[12:01pm] jmarino: I'm not sure we want to support that though...
[12:01pm] jmarino: it would be easy to do but it seems kind of weired
[12:01pm] rfeng: so the composite may have hybrid SCA & Spring
artifacts?
[12:01pm] jmarino: they key thing is Services and References are
managed by the SCA runtime
[12:02pm] jmarino: yea..but I think it is kind of strange
[12:02pm] rfeng: ok
[12:02pm] jmarino: that would mean a dev...
[12:02pm] jmarino: would be doing some things in Spring, some in SCA
for the same app with no partitions
[12:02pm] rfeng: right
[12:02pm] rfeng: mixed PM
[12:02pm] jmarino: exactly
[12:03pm] jmarino: I think the other thing is we don't want to
support componenttype side files
[12:03pm] jmarino: we just have spring provide us with stuff
[12:03pm] rfeng: right
[12:03pm] rfeng: Spring doesn't enforce the interface contract, right?
[12:04pm] jmarino: which contract?
[12:04pm] rfeng: I mean for a bean, you don't have to specify the
interface
[12:04pm] jmarino: for a Spring bean, if you use AOP and JDK proxies,
you have to have an interface....
[12:05pm] rfeng: yes
[12:05pm] jmarino: if you use CGLIB instead of JDK proxies then no, a
straight class will do
[12:05pm] jmarino: most people use JDK proxies with Spring
[12:05pm] rfeng: ok
[12:06pm] rfeng: is an interface required for componentType?
[12:06pm] jmarino: the one drawback is you can't do field-level
interception
[12:06pm] rfeng: right
[12:06pm] jmarino: no for SCA we don't require an interface for local
components
[12:06pm] jmarino: if you want policy though, it is required
[12:07pm] rfeng: ok
[12:08pm] ant_: jmarino, an interface is not required?
[12:08pm] ant_: what do you mean?
[12:08pm] jmarino: not for local
[12:08pm] jmarino: I can use a class
[12:09pm] ant_: but then there is an implicit interface which
includes the method on the class right? i can't have a javascript
component witout an interface which 'really' has no interface
[12:10pm] jmarino: yea that's right
[12:10pm] ant_: (...includes all the methods on the class...)
[12:10pm] ant_: ok
[12:10pm] rfeng: generated by asm?
[12:13pm] rfeng: I mean the implicit interface
[12:14pm] haleh left the chat room. (Read error: 104 (Connection
reset by peer))
[12:14pm] ant_: was just checking my understanding that a component
must have an interface. maybe its gen'd by asm, doesnt really matter.
anyway, carry on
[12:14pm] rfeng: ok
[12:15pm] jmarino: that's right, but from the impl perspective it
doesn't
[12:15pm] ant_: ok
[12:17pm] rfeng: what else? I think we had a good 1st round
[12:18pm] jmarino: I think we need to dig a little further into this
[12:18pm] jmarino: I'll take a look at the namespace handler you
wrote and bring it into the sandbox
[12:18pm] jmarino: in the meantime can you also do some further
research?
[12:19pm] rfeng: sure
[12:19pm] jmarino: maybe sync later today or am tomorrow?
[12:19pm] rfeng: maybe tomorrow, it's late for ant
[12:19pm] jmarino: oh yea sorry forgot
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
