[jboss-as7-dev] Metadata for AS

[Jason T. Greene]

On 2/21/11 1:22 PM, Andrew Lee Rubinger wrote:
> Alongside our metadata discussions this morning, I'd like to offer up a
> prototype for use as the preferred metadata view for AS subsystems.

-snip-

> The purpose of the project is to define an object model for
> specification and JBoss-specific metadata, with the following driving
> tenets:

One of the problems of any kind of metadata project, is that the scope 
is somewhat vague. It can be anything from just spec descriptors all the 
way to the entire runtime state of server deployment. Without a clear 
scope, it will likely feature creep towards the latter.
>
> * No compile dependencies outside the JDK
> * Pluggable backends (ie. DOM, XB, Stax, right now we use DOM and
> straight hardcoded parsing logic)

Why bother with pluggable backends? In particular whats the point of 
having both a DOM parser AND a STAX parser?

> * Easy import/export to/from File/URL/String/Stream/bytes
>
> Other concerns are to be addressed at another level, namely:
>
> * Merging
> * Annotation scanning repo output>  object model view
> * Validation
> * ...basically anything initiated during deployment.

This is a good start on specifying a scope. It sounds like an attempt to 
do a saner JSR-88 framework.

One of the challenges of using something like this for annotation 
processing is the assumption that there is a one-to-one relationship 
with annotations and configurable xml. This is not always the case. CDI 
for example has a large number of annotations to process that are only 
relevant to the actual CDI engine itself. This is not to say that there 
could not be value in some kind of xml override mechanism (originally in 
the draft specification), just that the consumers of interest are rather 
limited (just weld cares about this information). Also you probably 
don't want to have something that produces annotation java output.

>
> Deployment logic should be, IMO:
>
> Deployer takes in deployment>  Gen object model>  calls outside layers
> for merging/validation/etc>  deployer installs final view
That seems inline with what we have at the moment. The key thing though 
is that a deployer's state be allowed to evolve at the same pace as the 
deployer.

-- 
Jason T. Greene
JBoss, a division of Red Hat