Re: [proxy] Site Generation Issues...
The permissions on the live webserver are still wrong: [EMAIL PROTECTED] ls -alh | egrep '^d' proxy drwxrwxr-x8 apbackup apbackup 4.0K Aug 28 08:50 . drwxrwxr-x 28 apbackup apbackup 4.0K Aug 29 14:40 .. drwx--4 apbackup apbackup 4.0K Aug 28 15:50 apidocs drwx--4 apbackup apbackup 4.0K Aug 28 15:50 clover drwx--3 apbackup apbackup 4.0K Aug 28 15:50 images drwx--2 apbackup apbackup 4.0K Aug 28 15:50 style drwx--3 apbackup apbackup 4.0K Aug 28 15:50 xref drwx--3 apbackup apbackup 4.0K Aug 28 15:50 xref-test I'm not too sure about the details of rsync, how it is set up between minotaur and ajax nor how to trigger a permission update. I did 'touch' a few directories, maybe that'll make the problem go away. I don't have karma on ajax to chmod the files for you. What should always work is rm -r /www/jakarta.apache.org/commons/sandbox/proxy On minotaur. Then, wait at least 8 hours (I think). The files should be gone from ajax after that. Then, re-deploy the files on minotaur with a correct umask. I suggest you guys fix your website deployment process to ensure that any file that is created is actually created with the correct permissions. Oh, and response time from infrastructure can often be a week or more. We are lacking volunteers. Cheers, - LSD On 30-08-2005 03:01, James Carman [EMAIL PROTECTED] wrote: That trick didn't work. Anyone else have any ideas? I never heard anything back from the infrastructure team. -Original Message- From: James Carman [mailto:[EMAIL PROTECTED] Sent: Sunday, August 28, 2005 9:54 AM To: 'Jakarta Commons Developers List' Cc: [EMAIL PROTECTED] Subject: RE: [proxy] Site Generation Issues... Well, I touched all the files in /www/jakarta.apache.org/commons/sandbox/proxy, so I hope that works. But, I'm somewhat doubtful, because I completely blasted that directory's contents before I did the site:sshdeploy. -Original Message- From: Brett Porter [mailto:[EMAIL PROTECTED] Sent: Sunday, August 28, 2005 9:40 AM To: Jakarta Commons Developers List Subject: Re: [proxy] Site Generation Issues... It looks fine when viewed directly from minotaur, it seems the permissions are wrong on the live webserver (which is not minotaur). IF the permissions were wrong before and you fixed them, maybe they weren't synced - try touching the directory so it is synced again. Failing that, I suggest sending a query to [EMAIL PROTECTED] or dropping in to #asfinfra on irc.freenode.net. Cheers, Brett James Carman wrote: All, Sorry to be such a pest, folks. Almost everything is looking good. I added Proxy to the main Jakarta Commons page. I also switched Proxy to use the Jakarta Commons LF. The only problem I see is that any of the project reports that goes into a subdirectory (clover, Javadocs, etc.), causes a 403 Forbidden error. I would assume that the directories are not readable, but how do I change them? I looked at Commons Clazz's apidocs directory (on cvs.apache.org) and it's set up like: drwxrwxr-x 4 dirkv jakarta 512 Jan 4 2005 apidocs Commons Proxy's apidocs directory looks like: drwxrwxr-x 4 jcarman jakarta 512 Aug 27 23:49 apidocs Again, I hate to be such a bother, but I'm sure one of you guys will immediately know what to do and you'll probably point me to a link on the Apache site so as to say RTFM, gracefully. :-) Thanks, James - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: moving JAM to org.apache.jam
Noel J. Bergman wrote: [comments on stuff about JAM by Patrick Calahan] --- For those on the CC list: JAM is a metadata library combining features of the reflection API, JSR 175, commons-attributes, JClass and some other projects: http://www.pcal.net/jam that Patrick just introduced on [EMAIL PROTECTED] First impression: good stuff! Seems like a much better implementation of something I thought about here: http://www.jroller.com/comments/lsd?anchor=rethinking_attributes it would be so cool if you (Patrick) and Leo Sutic (the guy who wrote the current commons-sandbox-attributes) could get together and merge these two codebases (commons-attributes has some strengths that jam seems to lack, like being smaller and having what seems like a cleaner and easier runtime API, and vice versa the same is true of course) into a new de facto standard. Though I can't commit time to help coding right now, I'll volunteer to otherwise help you out with a quick progression through whatever process into whatever final destination. As to destination, jakarta-commons seems a natural choice to me. As to process, if jakarta-commons wants the code, you have a CLA on file, and the code was developed completely within an ASF repo @ xmlbeans, I don't think we need to have this go through incubation. It would just be up to jakarta-commons to accept it. The package name then would probably become org.apache.commons.meta or something like that. Please direct replies to [EMAIL PROTECTED] and drop the CC list. -- cheers, - Leo Simons --- Weblog -- http://leosimons.com/ IoC Component Glue -- http://jicarilla.org/ Articles Opinions -- http://articles.leosimons.com/ --- We started off trying to set up a small anarchist community, but people wouldn't obey the rules. -- Alan Bennett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[HiveMind] hivemind and avalon, revisited
Henri Yandell wrote: So how is Hivemind different to Avalon? Here we go again :D. I'll join in here to help get a sensible answer. Lets see if we can document it somewhere this time http://nagoya.apache.org/wiki/apachewiki.cgi?HiveMind/HiveMindAndAvalon (same content as this e-mail posted to the wiki) it's a more involved question than it seems... The problem domain for HiveMind and core Avalon is nearly the same; the general role of HiveMind in any application will be fairly similar to that of something like Avalon-Fortress or Avalon-Excalibur: providing configuration management, dependency setup, component instantiation, etc etc. = Design differences = Avalon takes that problem domain, then adds a strong containment concept (Avalon-Phoenix / Avalon-Merlin) in places, which comes with additional security, various kinds of standalone features, and corresponding extra setup. What avalon also adds everywhere is a strong emphasis on several patterns, like Inversion of Control, and a very rigid lifecycle (rules that boil down to set up logging then dependencies then create worker threads that are encoded in interfaces and enforced by containers) on every component. All this makes avalon rather heavy to apply a system. That's a disadvantage (lot of work, very much nonoptional dependency, some flexibility lost) and an advantage (rigid, clean, structured, common setup). HiveMind simply makes a few different choices, with its own set of advantages and disadvantages. There's no IoC, and various bits are /way/ more dynamic than is desireable in an IoC environment. Looking past all the features and history of both frameworks, this, IMO, is the actual big difference. Which answers the implicit question So why not combine HiveMind and Avalon into a single project?: there are a few core design choices that are different between HiveMind and Avalon that make the two distinctly incompatible. I might summarize that as Avalon is a very rigid kind of component framework, HiveMind acts a lot more like component 'glue'. = Concrete differences = For component writers and application assemblers (people who take a set of components and wire them together to make them actually do something), the differences are actually rather small. To show how small, I wrote http://nagoya.apache.org/wiki/apachewiki.cgi?AvalonAndOtherShinyContainers which shows you how your component can be portable across avalon, pico, spring, webwork/xwork, and I've now added HiveMind as well. Probably not too accurate, though. = Other frameworks = Howard M. Lewis Ship wrote: So there's definiately some overlap with Avalon. If I didn't have my day job, and the remaining work on Tapestry in Action, I'd love to survey all the current microkernels, including Avalon, Spring, Pico and so forth. I'm trying to maintain a wiki page to that effect: http://lsd.student.utwente.nl/jicarilla/RelatedProjects but its been difficult for me placing HiveMind in any kind of box, especially as its moving rather fast. hope this helps, cheers! - Leo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [HiveMind] hivemind and avalon, revisited
Howard M. Lewis Ship wrote: HiveMind simply makes a few different choices, with its own set of advantages and disadvantages. There's no IoC, and various bits are /way/ more dynamic than is desireable in an IoC environment. Looking past all the features and history of both frameworks, this, IMO, is the actual big difference. We need an industry standard definition of IoC then. indeed! I'll babble a bit more, see if we can converge on some common ground As I understand it, IoC means that a container is responsible for instantiating services, managing them, configuring them, connecting them together, and providing some amount of lifecycle support. Here's the terminology as avalon pioneered it (much narrower scope): Inversion of Control -- means exactly what it says: that your components are all set up completely from the top down (or from the outside in in the container-component view). This has farreaching consequences when universally applied. A component is only allowed to do what it is told. It is not normally allowed to do anything else, like look things up on its own (through JNDI for example, or any other kind of registry). That's it. IoC is not about lifecycle management, instantiation management, configuration, or anything like that. It's a concept. Okay, but what do you tell a component to do? That is where instantiation, management, composition, configuration, logging and similar aspects can come into play. All of those are concerns (among others) that /can/ exist in the relationship between container and component. Avalon makes the choice to draw big black lines between each of those concerns, and encode those choice rather bluntly and intrusively into interfaces, and hence, into all avalon components. This leads to a distinct component lifecycle. Avalon also makes the choice to enforce seperation of API and implementation (components can only access other components through interfaces), and several others. But all that doesn't /have/ to exist to call it IoC, nor is anything said about the complexity of the container-component contract, nor is anything said about which concerns that the container manages for a component. For example, PicoContainer is definately all about IoC, but it doesn't support any of the management, configuration, or logging concerns that avalon and hivemind do try to address, therefore it doesn't need any kind of lifecycle either. The only two things pico supports is composition (providing a component with its dependencies) and configuration (providing a component with user-designated runtime state). To achieve that, it does have to handle component instantiation as well, but tries to offload as much of that as possible to adaptors. You might see Pico as pure/minimal IoC with everything else stripped out. Now, you can /use/ HiveMind for an IoC setup. The big difference with avalon is that you can just as easily use HiveMind for a non-IoC setup. HiveMind itself (disclaimer: gathered from just a few quick glances at the sourcecode) also isn't totally saturated with IoC. Thus, HiveMind is more like component glue (much like Spring framework, which is remarkably similar on the surface). To IoC or not to IoC is left up to the HiveMind user. Right? OTOH, If you don't buy into IoC, you won't buy into Avalon. Outside of lifecycle support, HiveMind has all of that, mostly via the BuilderFactory. And this is something where we perhaps should attempt to foster some interoperability. Avalon-Fortress has a component factory concept; so does Pico (though they call it adapter now), so does hivemind. Figure out a way to share these factories cross-container and we might be halfway there. Of course, interoperability is not a sexy job; it is much more fun to code from scratch. I have been known to start from scratch several times a week. I might summarize that as Avalon is a very rigid kind of component framework, HiveMind acts a lot more like component 'glue'. I always like glue. Smells funny! marketing-hats/HiveMind/DuckTape//marketing-hat Close enough; added a few changes (large documenats are a pain in a Wiki, however, perhaps this should be split into multiple pages?) volunteering? ;) http://lsd.student.utwente.nl/jicarilla/RelatedProjects SoC IoC SAI DecP and AOP-lite HiveMind's geek code! hey, that's a wiki too! Meaning you're free (actually obliged according to http://lsd.student.utwente.nl/jicarilla/Welcome_20to_20the_20documentation_20team) improve on its contents :D cheers! - Leo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [GUMP] Build Failure - commons-attributes
Leo Sutic wrote: From: Sam Ruby [mailto:[EMAIL PROTECTED] This email is autogenerated from the output from: http://cvs.apache.org/builds/gump/2003-08-21/commons-attributes.html Buildfile: build.xml does not exist! Build failed It's a Maven project. How do I solve this? I note that some other sandbox projects have build.xmls that duplicate the Maven functionality. Is this the only way or is there a better one? at the moment, its the only way. For the avalon cvs repo I wrote a script that works a little differently, but I wouldn't recommend using that @ commons. There exist plans (in my head) to allow maven/gump integration) but none exists atm. Take a look at the documentation for the 'ant' and 'gump' plugins. You can generate the relevant files like so: maven ant maven gump cheers, - other Leo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [logging] To depend or not to depend?
robert burrell donkin wrote:
On Saturday, February 8, 2003, at 08:16 PM, Leo Simons wrote:
James Strachan wrote:
Would it be acceptable
to add a getName() or something similar to the Log interface and the
implementations? That way, we can fully implement the avalon-framework
Logger contract on top of commons-logging.
+1.
Seems reasonable to me. I guess it won't break anyones code who just use
commons-logging to log. The only risk is people who implement Log,
yep. It is a backwards-incompatible change there.
losing backward compatibility seems to me like it might open up a whole
can of worms. i worry that here in the commons we'd be left with major
incompatible problems between components based on the version of
commons-logging that they used.
a lot of time and debate was spent on the Log interface. as far as the
original idea is concerned, it's exactly right the way it is. once we
start changing the original concept, when do we stop?
rather than dive in and make changes to something which took literally
months of debate to get right (ie the Log interface), i'd prefer it if
we could look around for a solution which would preserve backwards
compatibility for this critical interface.
wouldn't it be better to either extend Log or create a Logger class
which implements Log but which has the extra method(s) that leo needs?
The problem is precisely in implementing such a Logger; you need the
right logger name in order to do something requiring that name. The
obvious change is to change the constructor signature to
CommonsLogger( Log log, String name ) { ... }
I need to do some thinking on the impact this has on code that needs to
create the loggers. Obviously, the avalon-framework Logger has a teeny
weeny little bit of information exposed which Log doesn't expose, and
there is no optimal route around it.
I think the new constructor is more acceptable than the change to Log,
meaning the additional method is unneccessary. The silly part is that
the logging name is known inside all the things Log abstracts away from,
yet not available through the interface. No API is ever perfect :D
Regardless, I think adding an additional base class or interface which
does provide the extra information is not a good idea: you keep the same
problem where components will depend on the new release with the new
interface in it.
ah, the wonderful world of spending hours deciding on a single method :D
cheers,
- Leo
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [logging] To depend or not to depend?
Leo Simons wrote:
What is probably perfectly doable is providing:
package org.apache.avalon.framework;
public class CommonsLoggingLogger implements Logger
snip/
this is on the TODO. Not for an upcoming avalon-framework 4.1.4, but it
might very well be in 4.1.5.
okay, so I took a closer look and just implemented this as it's real
easy to do. I actually did
public final class CommonsLogger implements Logger, Log { /* ... */ }
as that makes life even easier on component developers. One method
causes problems:
interface Logger
{
/**
* Create a new child logger.
* The name of the child logger is
[current-loggers-name].[passed-in-name]
* Throws codeIllegalArgumentException/code if name has an
empty element name
*
* @param name the subname of this logger
* @return the new logger
*/
Logger getChildLogger( String name );
}
as [current-loggers-name] is not exposed by Log. Would it be acceptable
to add a getName() or something similar to the Log interface and the
implementations? That way, we can fully implement the avalon-framework
Logger contract on top of commons-logging.
cheers,
- Leo
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [logging] To depend or not to depend?
James Strachan wrote:
Would it be acceptable
to add a getName() or something similar to the Log interface and the
implementations? That way, we can fully implement the avalon-framework
Logger contract on top of commons-logging.
+1.
Seems reasonable to me. I guess it won't break anyones code who just use
commons-logging to log. The only risk is people who implement Log,
yep. It is a backwards-incompatible change there.
but since
most of the implementations are inside commons-logging, it doesn't seem too
bad.
yep.
BTW did you mean to CC [EMAIL PROTECTED] or did you mean avalon-dev? :)
the latter of course. Silly me :D
I've attached a patch which adds a 'public String getName()' method to
Log and all implementations (relative to jakarta-commons/logging).
cheers,
- Leo
? Log.getName-patch.txt
Index: src/java/org/apache/commons/logging/Log.java
===
RCS file:
/home/cvspublic/jakarta-commons/logging/src/java/org/apache/commons/logging/Log.java,v
retrieving revision 1.13
diff -u -r1.13 Log.java
--- src/java/org/apache/commons/logging/Log.java15 Jun 2002 18:13:01 -
1.13
+++ src/java/org/apache/commons/logging/Log.java8 Feb 2003 20:09:15 -
@@ -275,4 +275,12 @@
public void fatal(Object message, Throwable t);
+/**
+ * p Get the name associated with this Log. /p
+ *
+ * @return the Log name
+ */
+public String getName();
+
+
}
Index: src/java/org/apache/commons/logging/impl/Jdk14Logger.java
===
RCS file:
/home/cvspublic/jakarta-commons/logging/src/java/org/apache/commons/logging/impl/Jdk14Logger.java,v
retrieving revision 1.4
diff -u -r1.4 Jdk14Logger.java
--- src/java/org/apache/commons/logging/impl/Jdk14Logger.java 17 Jul 2002 16:42:40
- 1.4
+++ src/java/org/apache/commons/logging/impl/Jdk14Logger.java 8 Feb 2003 20:09:16
+-
@@ -94,6 +94,7 @@
public Jdk14Logger(String name) {
logger = Logger.getLogger(name);
+ logName = name;
}
@@ -107,6 +108,10 @@
protected Logger logger = null;
+/** Name of the logger */
+protected String logName = null;
+
+
// - Public Methods
private void log( Level level, String msg, Throwable ex ) {
@@ -278,6 +283,16 @@
*/
public void warn(Object message, Throwable exception) {
log(Level.WARNING, String.valueOf(message), exception);
+}
+
+
+/**
+ * Get the name associated with this Log.
+ *
+ * @return the Log name
+ */
+public String getName() {
+return logName;
}
Index: src/java/org/apache/commons/logging/impl/Log4JCategoryLog.java
===
RCS file:
/home/cvspublic/jakarta-commons/logging/src/java/org/apache/commons/logging/impl/Log4JCategoryLog.java,v
retrieving revision 1.8
diff -u -r1.8 Log4JCategoryLog.java
--- src/java/org/apache/commons/logging/impl/Log4JCategoryLog.java 23 Nov 2002
03:49:40 - 1.8
+++ src/java/org/apache/commons/logging/impl/Log4JCategoryLog.java 8 Feb 2003
+20:09:16 -
@@ -293,4 +293,13 @@
public boolean isWarnEnabled() {
return category.isEnabledFor(Priority.WARN);
}
+
+/**
+ * Get the name associated with this Log4J Logger.
+ *
+ * @return the Log name
+ */
+public String getName() {
+return category.getName();
+}
}
Index: src/java/org/apache/commons/logging/impl/Log4JLogger.java
===
RCS file:
/home/cvspublic/jakarta-commons/logging/src/java/org/apache/commons/logging/impl/Log4JLogger.java,v
retrieving revision 1.1
diff -u -r1.1 Log4JLogger.java
--- src/java/org/apache/commons/logging/impl/Log4JLogger.java 23 Nov 2002 03:50:13
- 1.1
+++ src/java/org/apache/commons/logging/impl/Log4JLogger.java 8 Feb 2003 20:09:16
+-
@@ -291,4 +291,13 @@
public boolean isWarnEnabled() {
return logger.isEnabledFor(Priority.WARN);
}
+
+/**
+ * Get the name associated with this Log4J Logger.
+ *
+ * @return the Log name
+ */
+public String getName() {
+return logger.getName();
+}
}
Index: src/java/org/apache/commons/logging/impl/LogKitLogger.java
===
RCS file:
/home/cvspublic/jakarta-commons/logging/src/java/org/apache/commons/logging/impl/LogKitLogger.java,v
retrieving revision 1.2
diff -u -r1.2 LogKitLogger.java
--- src/java/org/apache/commons/logging/impl/LogKitLogger.java 17 Jul 2002 16:42:40
- 1.2
+++ src/java/org/apache/commons/logging/impl/LogKitLogger.java 8 Feb 2003 20:09:16
+-
@@ -90,6 +90,10 @@
protected Logger logger = null;
+/** Name of the logger */
+protected Logger logName = null;
+
+
//
Re: custom metatdata attributes
Jakob Praher wrote: hi all, as we (Leo and I) have talked about custom metadata attribute support for java lately, I wanted to know whether this should be done inside avalon, or should be delegated to another (jakarta) project. according to KISS, it should be a standalone library. There's lots of locations where something like that can be done. Sice Jakarta Commons already has some stuff regarding this in their sandbox I figured we'd start there. if inside avalon, I was wondering what approach towards implementing them should be taken. (class augmentation, manifest files, ...) I'm leaning towards parsing of /** @attribute SomeClassNameAttribute(blaat) */ class MyClass where an ant+qdox solution is run over this at build time. Such an AttributeParserTask could generate lots of stuff. The most important thing to agree on the syntax of the source files; you can always plug in lots of different generators. I would probably be most comfortable with this ending up in an xml file coupled to the class, ie something like: MyClass.attributes -- attributes attribute class=SomeClassName target=class constructor string value=blaat/ /constructor /attribute /attributes or maybe adopt the SOAP serializers from Axis for generation of everything inside attribute/. Something like that. (I believe .Net uses SOAP for serialization by default.) That's mostly because it is consistent with the approach avalon currently takes. I am curious about your opinons, me too :D I am actually waiting for a reply from some of the people who've done a lot of the meta/attribute stuff currently in place @ avalon, in particular Peter Donald (hi pete!). I suspect he's still catching up wrt e-mail...holidays y'know. and I am interested in helping with the implementation. That'd be neat! If you feel like getting started, the easiest thing to do is to probably check out jakarta-commons-sandbox, take the attribute code in there and run with it, then send patches to the commons list. I'm still orienting myself (still need to take a look at qdox/xdoclet first). The alternative is to try and drag requirements out of a broad group of people (I suspect potential interest is big :), but I'm guessing that's going to be difficult given the rather 'distributed' nature of that group. We'll go with the flow from there (I haven't been particularly active in commons before, but I believe I have commit rights to commons sandbox, so if there's no response it's probably okay for us to work on it there). cheers, - Leo -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
[general][attributes][clazz][A5] metadata the java world
Hi gang,
(commons peeps, my first post here I think, did read
http://jakarta.apache.org/commons/charter.html but couldn't find
anything on mailing list conventions so hope all is ok)
read a few books on .net 'n stuff last week. Got me thinking again on
metadata in the java world. I'm gonna throw an overview of various stuff
out at y'all, along with some thoughts. Additions/corrections much
needed I suspect ;)
.Net
.net stores metadata in compiled tables, basically mapping a reference
(to a class, object, method, whatever) to a serialized representation of
an attribute. An attribute is simply a serializable object extending a
base Attribute class, very bean-like in nature.
In C#, you apply attributes to objects by placing the constructor for
the attribute between square brackets, and optionally including a list
of properties to set.
here's how'd might work in Java.Net pseudocode:
[Avalon.Attributes.Lifestyle(singlethreaded, poolable=true)]
class MyClass {}
[Avalon.Attributes.Lifestyle(threadsafe)]
class MyClass2 {}
would be preprocessed into something like:
class MyClass
{
static public Attributes[] _att;
static
{
_att = new Attributes[1];
_att[0] = new Avalon.Attributes.Lifestyle(singlethreaded);
_att[0].setPoolable(true);
}
}
class MyClass2
{
static public Attributes[] _att;
static
{
_att = new Attributes[1];
_att[0] = new Avalon.Attributes.Lifestyle(threadsafe);
}
}
and the _att stuff is then serialize()d and stored into a table, ie
resulting in something like (in some hypothetical serialization format I
just made up):
MyAssembly.jar!/META-INF/ClassMetaData.properties
-
MyClass.attributes=array:1:Avalon.Attributes.Lifestyle(f0:singlethreaded:f1:*:f2:1):
MyClass2.attributes=array:1:Avalon.Attributes.Lifestyle(f0:threadsafe:f1:*:f2:*):
When the class loads, the attributes are deserialized and are then
easily accessible through introspection tools, ie you have something like
class AttributeUtil
{
public static boolean isSet(Object o,
String attributeName) { ... };
public static Attribute getAttribute(Object o,
String attributeName ) { ... };
}
There's more to it of course (for example, if you leave out constructor
argument and property info, you can leave off the (), and you can also
often do without the full package spec), but the basic idea is simple
enough.
Avalon
As putting [] in your sourcefiles is a bit troublesome (most editors
won't cope, for one), Pete (or someone else, doesn't matter, but he was
the first to commit some code dealing with this that I saw) had the
bright and obvious idea some time ago to put the metadata in the javadoc
comments instead, ie the modified example becomes:
/**
* @attribute Avalon.Attributes.Lifestyle(singlethreaded,
* poolable=true)
*/
class MyClass {}
/**
* @attribute Avalon.Attributes.Lifestyle(threadsafe)
*/
class MyClass2 {}
and as it is somewhat cumbersome to do actual preprocessing, the idea
was to just store the metadata information somewhere well-known (where
the utility classes would know how to find it). So instead of
MyAssembly.jar!/META-INF/ClassMetaData.properties
-
MyClass.attributes=array:1:Avalon.Attributes.Lifestyle(f0:singlethreaded:f1:*:f2:1):
MyClass2.attributes=array:1:Avalon.Attributes.Lifestyle(f0:threadsafe:f1:*:f2:*):
what we get is:
MyAssembly.jar!/MyClass.xinfo
-
Attributes
Lifestyle type=singlethreaded
poolable value=true/
/Lifestyle
/Attributes
MyAssembly.jar!/MyClass2.xinfo
--
Attributes
Lifestyle type=threadsafe/
/Attributes
So far so good. Of course, with a verbose xml format for storing the
metadata information, it is also possible to edit and maintain the xml
files by hand.
There's one big difference though: with .Net, basically their designers
figured out a compact way to specify the metadata by closely tying their
semantics to objects. The way we're going now, with the metadata dtds,
we loose some compactness, but more importantly the close ties are gone.
Custom metadata is more difficult with the avalon setup.
(note: none of the above actually works; it's just pseudocode examples)
--
Commons Attributes
--
Commons Attributes (which I just took a first look at) is more similar
to the .Net setup. It also uses QDox for parsing, but instead of
defining some xml scheme, simply stores a serialized properties file.
This is neat and simple (there's very little code neccessary to make it
all work, the attribute parsing being handled by QDox).
Commons Attributes atm doesn't define a standard location to store
attribute properties, nor does it contain code to automatically
