On Feb 17, 2006, at 8:14 AM, Kevin Williams wrote:
Jean-Sebastien Delfino wrote:
Jim Marino wrote:
Over the next several days, we are going to begin the cut-over to
the new bootstrap and proxy mechanism. I realize the
documentation has been lacking and it is difficult for people to
get up to speed on the changes. I hope to correct this as soon
as possible. In the meantime, a few pointers may help:
1. There are some slightly-out-of-date documents in my sandbox
that may provide an initial start. Jeremy has made a bunch of
improvements to the bootstrap and I have not had a chance to
incorporate his changes.
2. There are unit tests in core under o.a.t.c.runtime and
oa.t.c.system that show how to bootstrap a basic container.
3. The proxy building mechanism is still being heavily
refactored. I have a bunch of unit tests to in
o.a.t.c.invocation, o.a.t.c.builder, and
o.a.t.container.java.builder and o.a.t.container.java.integration
(the latter shows how proxy and wire builders will be integrated
with aggregate contexts). Some of the bigger changes were
separation of source and target side invocation chains, the
introduction of wire builders that are responsible for bridging
those sides, and the movement of TargetInvoker from the tail of
the target interceptor chain to being cached on the source side
and sent with the message for invocation. The last change allows
for optimizations such as being able to cache instance when a
source's scope is "shorter" than the target's scope (e.g.
session-->module).
During the cut-over, we will likely break the samples but not the
build.
While doing the cut-over, we'd also like to begin work on the
binding design. Sebastien had a bunch of good points/ideas here
so I will let him elaborate. Basically, we'd like to do the
binding work and cut-over in parallel.
Once we have these changes in place and the binding work under
way, it will hopefully be easier for us to make progress on the
roadmap Sebastien outlined on the wiki as well as make it easier
for people to contribute more actively.
Jim
Yes, a few more points:
- We're doing this because we'd like to get a stable runtime, be
able to run a number of significant scenarios, and crisp up our
story for plugging in bindings and component containers... by end
of next week. The goal here is to quickly get to a state where
it's easier for more contributors to get on board the project and
use, extend or integrate Tuscany. Our runtime is still using a
patchwork of old code and the new system/core code from Jim+Jeremy
and we need to complete the cut-over to this new code. I'm also
making changes to the assembly model with a cut-over to a POJO
model. In the next several days we are going to bring-up these
various pieces to get to the stable state where we want to be. We
may break a few things during that short period of time and won't
be able to guarantee that all the samples always work while we are
in the middle of that integration.
We should still follow our commitment to not break the build,
right? This includes successful completion of test cases run as
part of the build.
For the build, yes. However, for the tests It depends on what are
considered test cases. The unit tests and integration tests under src/
java/test of common,model, core, container.java, container.js,
tomcat, and binding.axis will all work. The acceptance tests and
samples may break. This should all be qualified that this will only
apply to the java container and not other projects. Unfortunately,
there is no way around this without doing a lot of work that will be
thrown away after the cut-over is complete. Sorry.
- People who don't want to be broken by these internal changes
because they're working on the samples or the acceptance test
suite should stay on the current SVN revision for a few days,
until we complete our bringup.
- Ant, I think you've started to look into how you plug in the
AXIS2 binding into the runtime. The changes in the bootstrap of
the runtime and the proxy building mechanism should not really
affect you (well maybe the proxy + invocation chain building
mechanism will change a little but that's not going to be big
revolution). The good news for you is that this is now going to
look very similar to how you plugged-in your JavaScript container
(so no big surprise). Also Jim is going to provide you with base
implementation classes of EntryPointContext and
ExternalServiceContext that will do what you need (very similar to
SimpleComponentContext), by Monday - looks like some of us are
going to be busy over the weekend :). We think that this will help
you get on board the new set of interfaces, you'll have base
classes that you can use as such or as a sample/guide for your
binding implementation.
--
Jean-Sebastien
_______________________________________________________________________
Notice: This email message, together with any attachments, may contain
information of BEA Systems, Inc., its subsidiaries and affiliated
entities, that may be confidential, proprietary, copyrighted and/or
legally privileged, and is intended solely for the use of the individual
or entity named in this message. If you are not the intended recipient,
and have received this message in error, please immediately return this
by email and then delete it.
