> -----Original Message----- > I'm sure Leo was writing down his thoughts so they were not forgotten. > > We do need to get back on the stick with the Meta Info stuff. I agree > with many of the points. We should separate out that into another > discussion.
Yep. > I am playing around with .NET and C# Avalon Framework. The Meta data in > C# is defined by something like this: > > type.IsDefined(typeof(MyProj.MyAttributeType), inheritable == true); > > Essentially I am talking about something like how our configuration is > set up. If anything, we can model Types, Methods (i.e. lifecycle), and > Assemblies. I'm still fuzzy about how I think this should work. There's lots of ways to do this. For example: - We already have the sandbox meta package which allows for quite a bit of meta data expressed in XML or doclet tags. This includes definitions of types, stages (lifecycles), dependencies, etc. - Use something like Commons Attributes [1] or some of the AOP designs from nanning [2] (in particular the AttributesCompiler). I think this falls more in line with the ideas mentioned by Leo and Ulrich in the recent "[RT] The Next Big Component Architecture" thread. just to mention two. One thing to keep in mind is that however it works, it must be transparent to the end developer (ie- KISS). > It would be easier to extend the system dynamically by allowing the > interface to querry if a type or method has a specific attribute or > not. That way things like JMX integration can be treated as an add-in, > and the JMX publishing tool will be able to see which methods and types > have the attributes set. What about using something like JXPath [3]? " XPath is the official expression language of XSLT. In XSLT you mostly use XPath to access various elements of XML documents. You can do that with JXPath as well. In addition, you can read and write properties of JavaBeans, get and set elements of arrays, collections, maps, transparent containers, various context objects in Servlets etc. In other words, JXPath applies the concepts of XPath to alternate object models. " At least I think that's close the idea we're looking for. > It was a metaphor. If we want to get away from ServiceSelector (which I > believe > we do), we need a way of mapping component implementations to each of > those > short names. For example, in Cocoon there are different types of > generators > and transformers and serializers. Each of them provides a different way > of doing things. A "file" generator is different from a "image-directory" > generator, etc. [snip] So we have two issues (If I understand correctly): 1. A proper naming scheme for ServiceManager lookups that allows us to get away from the ServiceSelector 2. A way of handling dynamic service dependencies (which are therefore unknown during the assembly process) is that right? > Let's start with the tools first, and see what evolves from there. We do > have existing functionality for instrumentation and management extensions. > We can refactor those and where we have common requirements, we can create > the Container Management API from that. agreed. jaaron [1] http://jakarta.apache.org/commons/sandbox/attributes/ [2] http://nanning.sourceforge.net/ (note- I think nanning is LGPL) [3] http://jakarta.apache.org/commons/jxpath/ --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
