Jim Marino wrote:
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.
As part of this "cut-over" work, I am checking in a number of
significant model changes. Here is a summary:
- ported the SCA runtime to our SDO2 implementation
- changed the logical assembly models to POJO models with no
dependencies on EMF and SDO, this includes the core assembly model as
well as the java component and web service binding models.
- generated SDO2 models from the SCDL XSD, this will be used to load
SCDL in an SDO2 object graph which we'll walk to populate the logical
assembly model; eventually we'll replace this by a first class StAX
based loader, but this approach gives us a cheap loading mechanism for now.
- similar changes to the message and endpoint reference models
- replaced the language-independent interface model that we were using
to represent service interfaces (InterfaceTypes... populated from WSDL
and Java) by... a native java.lang.Class, which is much simpler
- removed the org.osoa.sca.model interfaces, which were not really
usable anyway, we'll re-introduce a metadata API when the spec defines
what these interfaces should look like
- removed dead code in various places in core and container.java to
prepare for Jim's "cut-over" changes
- adjusted the POMs to use the EMF dependency JARs from the 02162006
integration build.
These changes are breaking changes. I adjusted the code in the core,
container.java and tomcat projects but binding.axis and container.js do
not compile yet. The AXIS 2 related work is carried in a separate
project in the sandbox at the moment so this shouldn't be a problem. I
need to check these changes now to allow Jim to merge-in his other
"cut-over" changes so I left some compile errors in some of the test
cases in core and container.java (which will not work anyway without
Jim's changes). To build these projects just do mvn -o
-Dmaven.test.skip=true. Jim, Jeremy, could you please take a look at
these test cases, most of them do not contain comments, some of them
take liberties with the semantics of the model (e.g. they use Pojo* mock
objects which implement the model in a different way with shortcuts,
sometimes they do not call the initialize() method on model objects
etc.) and I could use some help to understand what they do and port them
to the new model.
Next:
- Jim will merge his changes. We're doing a F2F hackathon tomorrow to
bring the runtime back up.
- I'll check-in the loaders/transformers used to transform the SDO2 SCDL
models to the logical assembly model tomorrow.
- I'll also add the SDO2 codegen maven plugin to the relevant POMs to
get the SCDL models generated as part of the build and will then remove
the SCDL model code from SVN - less code in SVN is always better :)
So again, if you need a stable build with no breaking changes, please
stay on the SVN revision that you are on. We'll probably continue in
this break/fix/bring-up mode for another day or two.
--
Jean-Sebastien
