From: Scott M S. <sco...@jb...> - 2005-11-20 19:29:41
|
In looking at the org.jboss.ws.metadata and org.jboss.aop.metadata: Good ws abstractions: - A MetaDataBuilder notion that abstracts out the source of the data. - Well typed pojo view of the metadata - An ability to export the pojo model to a "source". Bad ws abstractions: - No interfaces to help decouple implementation. - Usage of a URLClassLoader which may not exist. This is introducing an implementation dependency that we already have plans to get rid of. - Coupled to webservice data types. It looks like another MetaDataBuilder layered on top of the more generic abstraction could be used to incorporate overrides and non-deployment sources of metadata. - Use of the DeploymentInfo even at the AbstractMetaDataBuilder level. Good aop abstractions: - A MetaDataLoader notion that abstracts out the source of the data. - A simple metadata resolution/lookup notion. Bad aop abstractions: - The only loader interface class is coupled to class level metadata with xml overrides. Other sources of data only have class definitions and still have an aop specific interface for describing the metadata (fields, classes, methods). - The metadata resolution notion is coupled to an org.jboss.aop.joinpoint.Invocation as a required key. Having to start resolution at a thread/request level is too low of a scope, and the Where is the "improved deployment and type safety" thread? The abstractions that need to exist are: - A pojo metadata model with a loader abstraction that isolates the source of the metadata from the pojo model. The loader needs a notion of scope. - A metadata resolution service that supports a hierarchical linking of the pojo metadata model from the various scopes (thread, request, session, app/deployment, server, cluster/domain). Aspects should be able to interact with thread/request level metadata to introduce/override this. - A mapping to the profile service abstraction that allows for management tools, installers to introduce metdata via deployment level and higher loader abstractions. Adrian Brock wrote: > On Sat, 2005-11-19 at 15:11, Scott M Stark wrote: >> This is the point. First, what basis for a unified view of the metadata >> and management exists today > > It only really exists in aop land. > > The final solution is largely based on Bill's aop metadata, except with > improved deployment and type safety (mentioned on a different thread). > > The improved deployment is to have a repository where deployers > can establish component/application/server level metadata > and assign pojos/services to those levels such that > * invocations on these components have the correct metadata context > * decorators like management can retrieve the context/metadata > > I would prototype it, but I only have so many cycles. :-) |