At the moment the Java configuration model contains references to
artifacts associated with Java definitions - for example,
JavaImplementation references the actual Class for the
implementation. This works fine when all runtimes have access to the
applicable contribution artifacts that provide these definitions but
breaks down when we start to distribute the assembly model over a
heterogeneous domain.
To address this I am going to make changes to the model so that these
definition references can be represented as simple types - for
example, instead of using the actual Java Class, use its name and the
id for the contribution that provides its bytecode.
However, we still need information from these artifacts to determine
things like the component type, to introspect bindings and other
annotations, resolve autowires and verify composite structure. To
support this, I plan to add two new phases to the deployment process:
resolve and verify. The resolve phase will resolve these abstract
definitions into concrete model objects e.g. actually loading the
component type for an implementation. The verify phase will be
responsible for verifying that any model change is valid to make so
we can catch errors like duplicate component names.
--
Jeremy
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
