1:22 p.m.
Alongside our metadata discussions this morning, I'd like to offer up a
prototype for use as the preferred metadata view for AS subsystems.
We've baked in the testing community a project currently branded
"ShrinkWrap Descriptors":
GitHub: https://github.com/shrinkwrap/descriptors
JIRA: https://issues.jboss.org/browse/SHRINKDESC
The end user view looks a bit like:
https://gist.github.com/828591
The purpose of the project is to define an object model for
specification and JBoss-specific metadata, with the following driving
tenets:
* No compile dependencies outside the JDK
* Pluggable backends (ie. DOM, XB, Stax, right now we use DOM and
straight hardcoded parsing logic)
* 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.
Deployment logic should be, IMO:
Deployer takes in deployment > Gen object model > calls outside layers
for merging/validation/etc > deployer installs final view
The descriptors project is currently immature and could use a jumpstart
off the prototype. If we decide this is of interest to AS and
subsystems, that's enough of a demand for me to take it on exclusively
over the next few weeks to give us a cleaner, faster alternative to
jboss-metadata, which has in my opinion, the following drawbacks:
* The API *is* the backing model
* Too many dependencies
* Mixes in business logic (defaulting of values, spec validation)
* Not interface-based (resulting in wrapper classes and the like to tack
on functionality)
S,
ALR
5:09 p.m.
On Mon, 2011-02-21 at 14:22 -0500, 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.
We've baked in the testing community a project currently branded
"ShrinkWrap Descriptors":
GitHub: https://github.com/shrinkwrap/descriptors
JIRA: https://issues.jboss.org/browse/SHRINKDESC
Maybe we could think about redoing metadata for the next release ? For
this one it would make web integration go back to the start, while
there's still a lot that needs to be integrated and not much time left.
--
Remy Maucherat <rmaucher(a)redhat.com>
Red Hat Inc
5:42 p.m.
On 02/21/2011 06:09 PM, Remy Maucherat wrote:
On Mon, 2011-02-21 at 14:22 -0500, 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.
>
> We've baked in the testing community a project currently branded
> "ShrinkWrap Descriptors":
>
> GitHub: https://github.com/shrinkwrap/descriptors
> JIRA: https://issues.jboss.org/browse/SHRINKDESC
Maybe we could think about redoing metadata for the next release ? For
this one it would make web integration go back to the start, while
there's still a lot that needs to be integrated and not much time left.
Maybe true, but I don't only want to think only in terms of AS releases.
There's two other community projects which want this, so if AS is
interested, it can put things to the forefront now. And AS can bring it
in whenever it's ready.
So the question is: will AS want it in the future? If so, I can justify
the investment there now.
Also Remy, point me to the web integration parts? If I remove
jboss-metadata as a dependency from one or two projects, light
everything red, and then plug in this thing, it shouldn't take me long
to retool the lot. Assuming Descriptors gets built out and is good to go.
S,
ALR
6:25 p.m.
On Mon, 2011-02-21 at 18:42 -0500, Andrew Lee Rubinger wrote:
Also Remy, point me to the web integration parts? If I remove
jboss-metadata as a dependency from one or two projects, light
everything red, and then plug in this thing, it shouldn't take me long
to retool the lot. Assuming Descriptors gets built out and is good to go.
Yes, it needs to do the following: parse the spec descriptors using STAX
(like metadata does now; supposedly it is faster), provide a unified
view with the annotations, allow merging the descriptors using some
arcane rules (from the specification), and allow merging with a JBoss
specific descriptor (which allows overriding and proprietary settings).
The main rule is to make sure the standalone Servlet & JSP TCKs pass
before considering things are done.
--
Remy Maucherat <rmaucher(a)redhat.com>
Red Hat Inc
6:50 p.m.
On 02/21/2011 07:25 PM, Remy Maucherat wrote:
On Mon, 2011-02-21 at 18:42 -0500, Andrew Lee Rubinger wrote:
> Also Remy, point me to the web integration parts? If I remove
> jboss-metadata as a dependency from one or two projects, light
> everything red, and then plug in this thing, it shouldn't take me long
> to retool the lot. Assuming Descriptors gets built out and is good to go.
Yes, it needs to do the following: parse the spec descriptors using STAX
(like metadata does now; supposedly it is faster), provide a unified
view with the annotations, allow merging the descriptors using some
arcane rules (from the specification), and allow merging with a JBoss
specific descriptor (which allows overriding and proprietary settings).
STAX is an implementation detail. We're going for pluggable backends,
starting w/ straight DOM. From a user perspective it's all the same
view - spec and JBoss grammars only.
Unified view from annotations and merging is one and the same, right?
With any luck we can port the existing logic into whatever new model we
choose, as the merge stuff is extensive, error-prone, manual and
time-consuming.
The main rule is to make sure the standalone Servlet& JSP TCKs
pass
before considering things are done.
Agreed, with the additional footnote that I believe we should have our
own coverage in a usable testsuite (ie. JUnit, TestNG) which mirrors
TCK/compliant stuff at the unit level. Using the TCK alone for
acceptance testing wastes a lot of time, and should be avoided wherever
possible.
S,
ALR
6:52 p.m.
On 02/21/2011 07:50 PM, Andrew Lee Rubinger wrote:
Agreed, with the additional footnote that I believe we should have
our
own coverage in a usable testsuite (ie. JUnit, TestNG) which mirrors
TCK/compliant stuff at the unit level. Using the TCK alone for
acceptance testing wastes a lot of time, and should be avoided wherever
possible.
BTW, this is the main advantage of jboss-metadata at the moment - a
great testsuite which covers a large case of merge scenarios. No matter
how much we may want to move to a new model, we can't discount the
tremendous value this has already.
S,
ALR
9:31 p.m.
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
10:04 p.m.
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
10:28 a.m.
On 2/21/11 10:04 PM, Andrew Lee Rubinger wrote:
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.
OK, well the reason for StAX usage in AS is processing and memory
efficiency (something we definitely don't want to lose). DOM has the
negative impact of copying everything into a big object model so that
you can copy it again into a big object model. Granted its far more
efficient than JAXB based parsers.
>> * 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?
Yeah its very odd. It allows you to manipulate any descriptor as a chunk
of xml that is in your deployment based on an xpath mechanism.
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.
Yeah I can certainly see a lot of value in having a EE standard
descriptor manipulation API.
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.
Yes, I can see a spec defined xml descriptor API having a good potential
for reuse. JBoss xml descriptors potentially as well, although for
reasons I get into below, I think it needs to be limited to areas that
have a very strong and clear contract.
Also, due to the rapid AS schedule, I don't want to create new potential
blockers, at least in the 7.0 timeframe. When the project is further
along and the API is solid/battle tested, I think then would be a better
time to look at including it.
> 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
The point though is that annotation data does not always have a clear
correspondence in the XML. So your object model becomes a super set, and
represents the "merged view" (aka private deployer implementation details).
IMO any kind of descriptor API will be much easier to get right if its
modeled as a direct one-to-one view of each input.
>> 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?
So lets say you do the annotation -> bridge - > descriptor. Then we add
support for a new annotation. Now, how many libraries, APIs, classes,
releases are involved to make this change?
Another example, is lets say that the object model (and not the
descriptor) is wrong and uses a single value object instead of a list.
Since external users are using this, we now have to break an API to
update something that should just be an implementation change.
The two above reasons are why IMO this should closely reflect the
existing contracts, and not be a unified state abstraction.
--
Jason T. Greene
JBoss, a division of Red Hat
5023
days inactive
5024
days old
8 comments
3 participants
participants (3)
-
Andrew Lee Rubinger -
Jason T. Greene -
Remy Maucherat