[jboss-dev-forums] [Design of POJO Server] - Re: Updating docs

[scott.stark@jboss.org]

I guess the issue arises from trying to distinguish between classes of metadata attachments at the structural level: getPredeterminedManagedObjects, getTransientManagedObjects, getTransientAttachments.

Its not clear that this can be manged easily. There are two problems I see with getting to the ultimate, fully resolved metadata. I see two distinct classes of metadata: Configuration and Managment.

Both are built from different sources and scopes:
- annotations
- descriptors
- overrides: vendor descriptors, profile service/management tools
- aspects: deployment and runtime

Both are graphs of objects whose nodes can be populated at any level. This is the metadata repository notion we have, that is not explicitly part of the current vdf spi. I don't see how we can build the object graphs without the metadata repository notion integrated. The two problems are 1, piecewise population of the object graph nodes, 2, seamless usage of the final, merged object.

Let's take a concrete example of a java:comp/env object:


  | class Binding
  | {
  |    /** enc relative name of the binding */
  |    String name;
  |    /** type of the binding */
  |    Class type;
  |    /** value of the binding */
  |    Object value;
  | }
  | class Link extends Binding
  | {
  |    /** the raw link */
  |    String link;
  |   /** the raw link type */
  |    enum LinkType {JndiName, DeploymentRef, ...} linkType;
  |    /** the resolved name for the binding of the link */
  |    String resolvedName;
  | }
  | 
  | /** Some derived property that allows a mgmt tool to list the enc bindings */
  | @ManagedProperies({@MangedProperty("all-bindings") })
  | class ENCMetadata
  | {
  |    /** simple direct bindings in the enc */
  |    List<Binding> bindings;
  |    /** links to bindings outside of the enc */
  |    List<Link> links;
  | }
  | 

This info is going to come from all levels:
- annotations on the component the enc belongs to
- deployment descriptor overrides
- container overrides: for example, we introduce non-standard elements like the security domain name, current subject, as well as the standard container bindings; orb, tm, pm.
- references to profile service managed bindings. One example would be property style references to elements managed at higer levels such as server hostname, logical name, cluster name, ...
...

Ultimately an ENCAspect wants to install the javax.naming.Context for the ENCMetadata instance for the component its currently handling. Likewise, a management tools wants the to be able to display some representation of this Context.

How this is pulled together from the current vdf classes is far from clear for me with the current spi.


View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3973622#3973622

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3973622