Date: 2004-08-16T23:21:28
Editor: KenTam <[EMAIL PROTECTED]>
Wiki: Apache Beehive Wiki
Page: Controls/AssemblyAndBinding
URL: http://wiki.apache.org/beehive/Controls/AssemblyAndBinding
no comment
Change Log:
------------------------------------------------------------------------------
@@ -14,11 +14,12 @@
Control clients MUST declaratively identify all control types they use. This
is accomplished via 2 annotations, which are handled by the control client
annotation processor:
[EMAIL PROTECTED] -- marker annotation valid on fields; the annotated field's
type is a control type (directly, as a control interface/extension, or
indirectly as the generated ControlBean that implements a control
interface/extension).
[EMAIL PROTECTED] -- marker annotation valid on fields; the annotated field's
type is a control type (directly, as a control interface/extension, or
indirectly as the generated C''''''ontrolBean that implements a control
interface/extension).
[EMAIL PROTECTED] -- single value annotation valid on classes or methods; the
annotation's value specifies the a control type that the control client uses.
[EMAIL PROTECTED] are required whenever a client uses a control type in a
purely programmatic way (ie, there is no [EMAIL PROTECTED] annotated field of
that control type in the client).
-{{{TBD: elaborate on how this might work for clients that are Java-centric,
but aren't "plain Java code", e.g. JSPs, BPELJ, etc.}}}
+{{{TBD: elaborate on how this might work for clients that are Java-centric,
+but aren't "plain Java code", e.g. JSPs, BPELJ, etc.}}}
Both annotations have runtime retention policy; thus in principle, the
assembly process may accept a set of control clients made of up of a mixture of
source and binary classes, and use reflection to determine the set of control
types those clients use.
@@ -44,11 +45,14 @@
The default implementation binding for a control type is defined by the
defaultBinding attribute on the [EMAIL PROTECTED] annotation. The expectation
is that overriding the default binding is an unusual occurrence. The
conventional approach to overriding an annotation value would be via
[http://www.jcp.org/en/jsr/detail?id=88 deployment descriptors], however, since
the binding affects assembly, it needs to take place prior to application
deployment (we consider assembly to be properly part of the build).
{{{
-REVIEW: this almost suggests that assembly is part of deployment, but on
deeper thought that seems clearly wrong. I am not completely satisfied with
this yet. I think we need to really define crisply whether binding is a
developer or admin feature.
+REVIEW: this almost suggests that assembly is part of deployment,
+but on deeper thought that seems clearly wrong. I am not
+completely satisfied with this yet. I think we need to really
+define crisply whether binding is a developer or admin feature.
}}}
External configuration of bindings is supported via a "controls binding file",
an optional, user-authored, application scoped properties file that contains:
- * bindings between C''''''ontrolBean/interface types and control
implementation types. Each binding applies to all usages of the
ControlBean/interface type within that app.
+ * bindings between C''''''ontrolBean/interface types and control
implementation types. Each binding applies to all usages of the
C''''''ontrolBean/interface type within that app.
Example controls binding file (e.g. {{{MyApp.controls.properties}}})
{{{
@@ -57,7 +61,8 @@
}}}
{{{
-REVIEW: Do we need finer granularity over binding configuration? This
approach can be extended to client-scoped config files.
+REVIEW: Do we need finer granularity over binding configuration?
+This approach can be extended to client-scoped config files.
}}}
== The Assembly Process ==
@@ -71,8 +76,10 @@
For a J2EE module type to support control clients, there must be provided an
implementation of the
[http://svn.apache.org/viewcvs.cgi/incubator/beehive/trunk/controls/src/api/org/apache/beehive/controls/api/assembly/ControlAssemblyContext.java?rev=&root=Apache-SVN&view=markup
ControlAssemblyContext] interface, which exposes the characteristics of the
module to the assembly process (ie, providing access to file system locations
so files can be added to the module, providing access to read/modify
descriptors, etc).
{{{
-TBD: Add message logging functionality to ControlAssemblyContext so
implementations can emit diagnostics to assembly tools.
-TBD: Expose more abstract operations like "addEjbRef()" on
ControlAssemblyContext.EJBModule, rather than just raw "getEjbJarXml()".
+TBD: Add message logging functionality to ControlAssemblyContext
+ so implementations can emit diagnostics to assembly tools.
+TBD: Expose more abstract operations like "addEjbRef()" on
+ ControlAssemblyContext.EJBModule, rather than just raw "getEjbJarXml()".
}}}
The assembly process:
