Comments inline
On Jul 4, 2006, at 7:16 AM, Jojo wrote:
Hi,
I was trying to understand the sandbox and having difficulty in
making out
things. I thought I will bring some of these into this thread. I would
appreciate if somebody can helpme understand better.
1. Where is the client programming model ? I find some sample code in
samples\src\main\java\eagerinit\EagerInitClient.java, but this
doesn't work
(fails with an NPE). But there is another class called
\samples\src\main\java\eagerinit\LifecycleDemonstration.java which
works.
Just to give a little background, eagerinit was not intended to show
an end-user programming model. Rather, it is just an example of how a
component lifecycle works from the perspective of the internal
workings of the container. This was in response to people wanting to
be able to step through the internal execution flow of core2.
Also we would not expect client code to bootstrap the container in
this manner; it's just for illustrative purposes since people had
questions about the internal workings of the container.
One of the programming models for Tuscany Java will be the SCA Java
C&I spec. Spring will be another. And, there can be many more
depending on what people want to implement.
Related to the Java C&I model, we're in the process of integrating
recent spec changes into the core, including:
1. Switch to nested composites
2. Generified API
3. Tighter definition of property and reference heuristic determination
4. Support for constructor-based injection
5. Changes to scope semantics
One of the key things about SCA (and most IoC containers) is that the
programming model and container are (almost) completely separate.
Most applications should never need to make an API call unless they
require access to a very low-level capability (the Java SCA API fits
onto on slide, normal font size). We on the spec took great care to
make sure we did not unnecessarily "bleed" the container into
application code (I'm sure we missed a few spots though). Those of us
who are also working on Tuscany are committed to making sure this is
also the case with the core implementation as well and that it
reflects the design principals laid out in the specifications.
But the code there is too complex to be a client programming model.
Is this
the proposed client programming model ?
Completely agreed. This is definitely not the proposed client
programming model, the Java C&I spec and Spring are (there are others
such as Groovy too). It sounds as if you have some ideas on client
programming models and possible extensions to the existing ones. I'd
be interested in hearing about those both from a Tuscany and
specification perspective.
I would expect something like the
TuscanyRuntime class in M1 which I don't find any more.
There will be something similar to TuscanyRuntime; I believe Rick is
working on it.
2. I find in
\sca\core2\src\main\java\org\apache\tuscany\core\launcher
\MainLauncher.java,
line number 134, it is loading "eagerinit.composite". Why is it
doing that ?
And is this file loaded from the samples project ?
Glancing at it, it's loading the composite SCDL using the system
classloader of the Launcher. Rick did this design and it makes sense
to me as an elegant way to enforce classloader isolation with the
core. I've seen similar approaches work well, including:
- http://jetty.mortbay.org/jetty/index.html
- http://nanocontainer.codehaus.org/Booter
3. There was a discussion on the container.java in the mailing list.
(thread:
http://www.mail-archive.com/tuscany-dev%40ws.apache.org/
msg04165.html) I
didn't see any conclusion. And there is no container,java in the
sandbox. So
is it already merged with core ?
The discussion basically ended with no one able to come up with a
"good" solution so I choose what I thought was the lesser of two
evils: merging container.java into the core. This move entailed about
five classes and if someone can come up with a suitable alternative,
I'd be more than willing to implement it since I'm personally not
happy with the current solution (although I am happier with it than
the alternatives we had).
warm regards,
jojo.
On 7/4/06, Jeremy Boynes <[EMAIL PROTECTED]> wrote:
On 7/3/06, ant elder <[EMAIL PROTECTED]> wrote:
> I struggle with understanding the what and why of parts of the
sandbox
code
> and hope bringing small bits over one step at a time will help with
this.
>
What things are you struggling with? Perhaps clearing those up would
clear the air (as well as help with the documentation).
--
Jeremy
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
