[jboss-as7-dev] Metadata for AS

[Andrew Lee Rubinger]

On 02/21/2011 10:31 PM, Jason T. Greene wrote:
> 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.

Exactly, the idea behind this one is to offer nothing aside from an 
object view of spec metadata, along with import/export utils.  Its scope 
is intentionally limited.  And as you've noted below, I gave an overview 
of the proposed scope further down the email.

>> * 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?

The design is pluggable, but I've no plans slated ATM for any other 
backends besides DOM.  For instance Remy specifically mentioned StAX, so 
if he were so inclined he could provide that backend and user code 
wouldn't know the difference.  Or, alternatively we could actually use 
the existing jboss-metadata stuff as the backend, and use this as a user 
view atop.  Swapping out jboss-metadata later when we wanted.

>> * 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.

JSR-88 is a weird beast.  It's a deployment spec which also exposes out 
deployment configuration for tooling?

The itch which lead to this project's inception was from the testing 
community; users wanted to be able to mock out servlet configs in java 
code, and send 'em off for deployment in ShrinkWrap.

But I think we could be well served to adopt it here as the agreed view 
for AS subsystems.  Because the API does little more than expose 
spec/JBoss metadata grammars (and brings in no dependencies), I think 
we've got a good chance of agreeing upon this model.

> 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.

This is a problem, but not one for the Descriptors project.  What we'd 
need here is a bridge between the annotation provider/index (I'm aware 
of a few we've mocked up already) and the Descriptor model.

Annotation processor > index > bridge > Descriptor model

>> 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.

Can you expand on the "deployer state evolving" bit?  I'm near certain 
Descriptors wouldn't be imposing on anything here, but let's clarify?

S,
ALR