You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Leo Sutic <le...@inspireinfrastructure.com> on 2003/08/10 16:13:58 UTC
Attributes Proof of Concept
A while ago I suggested that using attributes may be a way out of the
problems we're having with meta models. The response then was that
the idea sure seemed nice, but the implementation of the idea sure
seemed nonexistent.
I have now whacked together a proof-of-concept for my idea. This is what
it
does:
1. You start off by defining your attributes:
import org.apache.avalon.attributes.Inheritable;
/**
* Declares a dependency.
*
* @Inheritable ()
*/
public class Dependency {
private final Class clazz;
private final String name;
public Dependency (Class clazz, String name) {
this.clazz = clazz;
this.name = name;
}
public Class getDependencyClass () { return clazz; }
public String getDependencyName () { return name; }
public String toString () {
return "[Dependency on " + clazz.getName () + " via name \""
+ name + "\"]";
}
}
Note that the class doesn't have to be serializable. Also note the
@Inheritable attribute
that this attribute has. This means that Dependency attributes are
inherited.
2. You mark your classes:
/**
* @Dependency ( SampleService.class, "super-sample" )
*/
public class SuperClass { ... }
/**
* @Dependency ( SampleService.class, "sample" )
*/
public class Sample extends SuperClass { ... }
3. Use the attribute compiler before compiling:
<taskdef
name="attributes"
classname="org.apache.avalon.attributes.compiler.AttributeCompiler"
classpath="bin/xdoclet-xjavadoc-1.0.jar;bin/commons-collections-2.1.jar;
../compiler/target/classes/"
/>
<!-- Precompile. -->
<attributes destDir="temp/">
<fileset dir="src/test/" includes="**/*.java"/>
</attributes>
<!-- Compile everything, including the classes generated above.
-->
<mkdir dir="target/classes/"/>
<javac destdir="target/classes/"
classpath="api/target/classes"
debug="true"
deprecation="true">
<src>
<pathelement path="src/test/"/>
<pathelement path="temp/"/>
</src>
</javac>
4. Run it:
Getting attributes for class Sample...
Sample has the following class attributes:
[
[Dependency on org.apache.avalon.attributes.test.SampleService
via name "super-sample"],
[Dependency on org.apache.avalon.attributes.test.SampleService
via name "sample"],
]
Note that Sample inherited an attribuet from its superclass.
The code is in avalon-sandbox/attributes. You should be able to check it
out and run
maven to compile everything. Since I'm not very good with Maven, the
demo, and the
compiler, are written for Ant. I hope to change this.
... check out ...
c:\home>maven && ant
Dependencies
------------
The compiler is dependent on Ant (since it is an Ant task) and on
XJavadoc-1.0. I tried XJavadoc-1.2b2,
but there were some methods missing, and I couldn't for the life of me
figure out how to adapt my
source.
The runtime package is 9kB and has no dependencies beyond the standard
Java Runtime. No XML parser,
no nothing.
Why not Attrib4J?
-----------------
I spent some time with Attrib4J, and I wasn't satisfied, so I decided
to write my own attribute compiler. At the very least I wanted to
know how I would like to modify Attrib4J, should I decide to go
that way instead.
My issues with Attrib4J are:
+ Stores attributes as serialized objects. This means that we have
to deal with serial version incompatibilities. You can have two
classes that are compile-time compatible, and runtime-compatible,
but not serial-version compatible.
+ Not quite so good API. Requires attributes to implement an Attribute
interface, be serializable and so on. We know where marker interfaces
lead. (Now we do, at least!)
Berin's Question
----------------
Berin asked something like this sometime:
"How can I get a list (or collection) of all classes with a certain
attribute?"
The academic answer is:
"You can't. Since classes are loaded on demand, and may even be
generated
dynamically, there is no way to get a list of all classes, let alone
filter
that non-existent list based on attributes."
The shorter answer is:
"Iterate over all jars, for each class found, ask for its attributes."
My Question
-----------
When attaching an Inheritable attribute to a class, it means that any
subclass
will also have that attribute attached to it. This is fairly obvious.
When attaching an Inheritable attribute to a method, it means that any
method
in a subclass that overrides the method will also have that attribute
attached
to it. This is also fairly obvious.
But: What happens if you attach an inheritable attribute to a field or a
Constructor?
Fields aren't inherited in the same way as methods:
public class Test {
public static class Super {
protected int v = 0;
public void sup () {
System.out.println ("v = " + v);
}
}
public static class Sub extends Super {
protected int v = 1;
public void sub () {
System.out.println ("v = " + v);
}
}
public static void main (String[] args) throws Exception {
Sub sub = new Sub ();
sub.sup ();
sub.sub ();
}
}
Output is:
v = 0
v = 1
Constructors aren't inherited, so their attributes shouldn't either, or?
Fields are inherited, but not in the same way as methods, so their
attributes
shouldn't follow as well, or?
/LS
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Attributes Proof of Concept
Posted by Leo Simons <le...@apache.org>.
Leo Sutic wrote:
> A while ago I suggested that using attributes may be a way out of the
> problems we're having with meta models. The response then was that
> the idea sure seemed nice, but the implementation of the idea sure
> seemed nonexistent.
>
> I have now whacked together a proof-of-concept for my idea.
neat! Seems to be working :D
<snip/>
> What happens if you attach an inheritable attribute to a Constructor?
IMO: it is not inherited. a call to super(/* blah */) had better still
respect the attributes applying to that parent constructor, though.
I would think the real messy part is with default constructors and/or
implicit calls to super():
class Super
{ /** @Blah() */
Super() { /* ... */ };
}
class Sub
{
}
does '@Blah()' apply to the default constructor of Sub?
> What happens if you attach an inheritable attribute to a Field?
>
> public static class Super { protected int v = 0; }
> public static class Sub extends Super { protected int v = 1; }
that is, imo, pretty ugly code :D. But yes, it should be dealt with.
> Fields are inherited, but not in the same way as methods, so
> their attributes shouldn't follow as well, or?
as long as a field definition is not overridden in a subclass, the
attributes should stay:
public static class Super { protected int v = 0; }
public static class Sub extends Super {
blah() { System.out.print(v); }
}
prints 0, of course. When a field definition is overridden, it is not
really 'overridden', but it is *hidden*. Its attributes should stay (so
that the parent class can access the attributes of its own field), but
not apply to the new attribute in the subclass.
At least, that seems consistent to me. Can it be implemented, is a
folluwup question :D
cheers,
- Leo
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Attributes Proof of Concept
Posted by hammett <ho...@cimcorp.com.br>.
----- Original Message -----
From: "Berin Loritsch" <bl...@apache.org>
> It is pretty messy to have to iterate over classes, but doable if
necessary.
> I would prefer a way to discover components that are already loaded on the
> classpath. That may not be possible.
Berin, why this approach? Even .Net doesn't supports such thing. Maybe we
should
find another strategy like inspecting classes on demand and not in the start
up.
What do u think?
hammett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Attributes Proof of Concept
Posted by Berin Loritsch <bl...@apache.org>.
Leo Sutic wrote:
> OK, I have added some code to scan ClassLoaders:
>
> URLClassLoader cl1 = new URLClassLoader (new URL[]{new File
> ("api/target/cl1/").toURL ()}, getClass().getClassLoader ());
> URLClassLoader cl2 = new URLClassLoader (new URL[]{new File
> ("api/target/cl2/cl2.jar").toURL ()}, getClass().getClassLoader ());
>
> ClassLoaderUtil clUtil = ClassLoaderUtil.getClassLoaderUtil ();
>
> Collection cl1Classes = clUtil.getClasses (cl1);
> Collection cl2Classes = clUtil.getClasses (cl2);
>
> System.out.println (cl1Classes);
> System.out.println (cl2Classes);
>
> Its in avalon-sandbox/attributes.
>
> In addition, there's an:
> public static Collection getClassesWithAttributeType (Collection classes,
> Class attributeClass)
>
> in Attributes.
>
> Will this fulfill your needs?
I believe so. Excellent work!
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Attributes Proof of Concept
Posted by hammett <ha...@uol.com.br>.
----- Original Message -----
From: "Niclas Hedhman" <ni...@hedhman.org>
> What happened to the XP voices in Avalon.
> Value; SIMPLICITY
I tried to say that too.. :-(
hammett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
RE: Attributes Proof of Concept
Posted by Leo Sutic <le...@apache.org>.
Niclas Hedman wrote:
> Sorry to butt in...
>
> What happened to the XP voices in Avalon.
> Value; SIMPLICITY
>
> The simplest solution that can possibly work!
>
> Since the whole Attribute world requires tools, such as an Ant
> task or a standalone compiler, why not let that tool create the
> index file, and for each URI in the classloader just get the
> "/index.attrs", which can be fully populated with the whole
> sha-bang....
That depends on what "the simplest solution" is. The whole point of the
attribute compiler is to gather up *all* metadata and pass it on, in order
to have a single tool for that purpose instead of having a Fortress
metadata builder, Merlin metadata builder and so on...
So the attribute compiler compiles attributes and nothing else.
If you want an index.attrs then fine, but that is
a. *another* contract on top of everything.
b. Probably not supported under Java 1.5.
(a) makes your claim of the simplest thing fall.
(b) makes it fall even further. When Java gets attributes it will most
certainly *not* support your index.attrs. This means that, since the
syntax for attributes will have changed, will have to:
1. Write an "attribute indexer tool" that must be run.
2. Stick with "our" attributes.
The objective with this proof-of-concept is to show that everything can be
solved with attributes and that we won't need *any* custom tools as soon
as Java1.5 is out.
The index.attrs moves a lot of ugliness into the Attribute compiler and
adds contracts and makes us incompatible with Java 1.5 in a much greater
degree than we are now.
Recursively loading classes moves a lot of ugliness into the classloading
code, but will work in Java 1.5 as well.
It is not so clear cut what the simplest solution is.
Stephen McConnell wrote:
> Basically the jar file is scanned for meta-info entires
That sounds similar to Niclas's index.attrs approach. Again, I wanted to
see if attributes would allow us to *only use attributes* and not have any
specific packaging requirements.
Finally, regarding the speed of loading classes:
1. The containers have hot-deploy features meaning that the applications
are loaded into separate classloaders managed by the container. This means
that we only really have to scan the classloaders that the container uses
to load applications.
2. My experience is that just about every class ends up being loaded
anyway, sometime during server startup. So if this massive loading is done
at t=0 or gradually throughout the startup sequence is irrellevant. The
same goes for applications in the app server - load all classes
immediately or gradually during startup of application is really no
difference.
/LS
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
RE: Attributes Proof of Concept
Posted by Niclas Hedhman <ni...@hedhman.org>.
<quote who="Leo Sutic">
> OK, I have added some code to scan ClassLoaders:
>
> URLClassLoader cl1 = new URLClassLoader (new URL[]{new File
> ("api/target/cl1/").toURL ()}, getClass().getClassLoader ());
> URLClassLoader cl2 = new URLClassLoader (new URL[]{new File
> ("api/target/cl2/cl2.jar").toURL ()}, getClass().getClassLoader ());
>
> ClassLoaderUtil clUtil = ClassLoaderUtil.getClassLoaderUtil ();
>
> Collection cl1Classes = clUtil.getClasses (cl1);
> Collection cl2Classes = clUtil.getClasses (cl2);
>
> System.out.println (cl1Classes);
> System.out.println (cl2Classes);
>
> Its in avalon-sandbox/attributes.
Sorry to butt in...
What happened to the XP voices in Avalon.
Value; SIMPLICITY
The simplest solution that can possibly work!
Since the whole Attribute world requires tools, such as an Ant task or a
standalone compiler, why not let that tool create the index file, and for
each URI in the classloader just get the "/index.attrs", which can be
fully populated with the whole sha-bang....
No need for recursive loading of classes (=very slow startups) and works
on non-JAR class repositories as well.
My 0.02 ringgit.
Niclas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Attributes Proof of Concept
Posted by Stephen McConnell <mc...@apache.org>.
Leo:
Have not had a chance to dig into what your doing just yet - but in the
meantime, have you taken a look at the curent approach in Merlin.
Basically the jar file is scanned for meta-info entires (no classloading
involved) and the meta info is loaded into a type repository. This
eliminates any need for a custom classloader. Also, the seperate type
repository provides the directory of available components - so you go to
the type repository to locate a component that provides a service, and
once located, you then worry about classloader via usual channels.
Stephen.
Leo Sutic wrote:
>OK, I have added some code to scan ClassLoaders:
>
>URLClassLoader cl1 = new URLClassLoader (new URL[]{new File
>("api/target/cl1/").toURL ()}, getClass().getClassLoader ());
> URLClassLoader cl2 = new URLClassLoader (new URL[]{new File
>("api/target/cl2/cl2.jar").toURL ()}, getClass().getClassLoader ());
>
> ClassLoaderUtil clUtil = ClassLoaderUtil.getClassLoaderUtil ();
>
> Collection cl1Classes = clUtil.getClasses (cl1);
> Collection cl2Classes = clUtil.getClasses (cl2);
>
> System.out.println (cl1Classes);
> System.out.println (cl2Classes);
>
>Its in avalon-sandbox/attributes.
>
>In addition, there's an:
>public static Collection getClassesWithAttributeType (Collection classes,
>Class attributeClass)
>
>in Attributes.
>
>Will this fulfill your needs?
>
>/LS
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
>For additional commands, e-mail: dev-help@avalon.apache.org
>
>
>
>
>
--
Stephen J. McConnell
mailto:mcconnell@apache.org
http://www.osm.net
Sent via James running under Merlin as an NT service.
http://avalon.apache.org/sandbox/merlin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
RE: Attributes Proof of Concept
Posted by Leo Sutic <le...@apache.org>.
OK, I have added some code to scan ClassLoaders:
URLClassLoader cl1 = new URLClassLoader (new URL[]{new File
("api/target/cl1/").toURL ()}, getClass().getClassLoader ());
URLClassLoader cl2 = new URLClassLoader (new URL[]{new File
("api/target/cl2/cl2.jar").toURL ()}, getClass().getClassLoader ());
ClassLoaderUtil clUtil = ClassLoaderUtil.getClassLoaderUtil ();
Collection cl1Classes = clUtil.getClasses (cl1);
Collection cl2Classes = clUtil.getClasses (cl2);
System.out.println (cl1Classes);
System.out.println (cl2Classes);
Its in avalon-sandbox/attributes.
In addition, there's an:
public static Collection getClassesWithAttributeType (Collection classes,
Class attributeClass)
in Attributes.
Will this fulfill your needs?
/LS
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
RE: Attributes Proof of Concept
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> From: Berin Loritsch [mailto:bloritsch@apache.org]
>
> > Idea:
> > How about this. We include in the MANIFEST.mf a list of all
> classes in
> > the JAR. That's it. Just one big list. That is the only packaging
> > requirement.
> >
> > Then we solve everything else at runtime.
> >
> > Then we can load classes and index them and so on as
> needed, but the
> > packaging requirements are fixed and dead simple.
>
>
> Excellent. Now the official JAR packaging takes advantage of
> an "index" service to help a classloader know what is in the JAR.
> I think the JAR utility can automatically create this "index" file--so
> all we have to do is specify that Avalon JARs need to use the indexing
> feature.
>
> Bam. Simple solution, minimal coding.
Sadly, the indexing feature only include the package names in a JAR.
What you have to do is this:
1. Get the classloader.
2. Get the URLs it uses (if it is a URL class loader, otherwise you're
out of luck).
3. Open a JarURLConnection.
4. Call JarURLConnection.getJarFile() to get a JarFile
5. Call JarFile.entries() to get a list of everythign in the Jar file.
6. Iterate over the entries, and for each .class file, load the
corresponding class.
7. Check the attributes of the class and index it as needed.
So the API would be:
public Collection getClasses (URLClassLoader cl);
public Collection getClassesWithAttributeType (Collection allClasses,
Class attributeType);
*No* packaging requirements.
I can include that in the Proof-of-concept.
It doesn't work very well for classes loaded over http from a directory,
or
from a database, but as long as the classes are in JARs, we're fine.
Maybe one should provide a pluggable way of scanning for classes:
public interface ClassLoaderScanner {
// What type of classloader can you scan?
public Class getClassLoaderType ();
// OK, scan this one, then.
public Collection scan (ClassLoader cl);
}
public class URLClassLoaderScanner implements ClassLoaderScanner {
public Class getClassLoaderType () {
return URLClassLoader.class;
}
public Collection scan (ClassLoader cl) {
...
}
}
public class ClassLoaderUtils {
public static void addClassLoaderScanner (ClassLoaderScanner cls);
public static Collection getClasses (ClassLoader cl);
}
/LS
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Attributes Proof of Concept
Posted by Berin Loritsch <bl...@apache.org>.
Leo Sutic wrote:
<snip more cool stuff>
>
>
> OK, how about this:
>
> /**
> * Gets a list of all classes with a specific attribute.
> * The requirements are:
> *
> * + The URLClassLoader must either point to...
> * ...a local JAR file or
> * ...a local directory or
> * ...a remote JAR file that will be downloaded in its entirety
> and examined
> */
> Class[] findClassesWithAttributeType ( URLClassLoader loader, Class
> attributeClass );
>
> You can get the URLs used the an URLClassLoader via the getURLs method,
> and we can
> get all the ugly iteration stuff in one place.
>
>
> Idea:
> How about this. We include in the MANIFEST.mf a list of all classes in
> the JAR.
> That's it. Just one big list. That is the only packaging requirement.
>
> Then we solve everything else at runtime.
>
> Then we can load classes and index them and so on as needed, but the
> packaging
> requirements are fixed and dead simple.
Excellent. Now the official JAR packaging takes advantage of an "index"
service to help a classloader know what is in the JAR. I think the JAR
utility can automatically create this "index" file--so all we have to do
is specify that Avalon JARs need to use the indexing feature.
Bam. Simple solution, minimal coding.
>
>
>>Automatic discovery of components and such will enable things
>>like IDE plugins and ANT tools to assist the developer as
>>they create and deploy the system.
>
>
> Just a big list of classes would probably do it. What you
> then do with that big list can be left to the application.
>
> It depends on how stable and sophisticated we want the packaging
> requirements
> to be.
Ok. If we can guarantee (or at least specify the index list) then
we can create the attribute finding algrorithm in that manner.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
RE: Attributes Proof of Concept
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> From: Berin Loritsch [mailto:bloritsch@apache.org]
>
> I noticed you used XDoclet instead of QDox. Any particular
> reason why?
XDoclet isn't really used - I only use the XJavadoc part of it.
The reason is simply that I wasn't aware of QDox at the time I
wrote the code.
I started with XDoclet, because I though it would be the best
thing to use - but then I realized that the functionality I
wanted was in XJavadoc and switched to it.
What I miss (both in XJavadoc and QDox) is the ability to easily
get the line number and file a tag is in. See, when generating
classes, suppose you have an attribute whose constructor takes
and integer:
public class MyAttribute {
public MyAttribute (int i) { ... }
}
And then you make a slight error, giving it a String instead:
/**
* @MyAttribute ("hello?")
*/
or misspell the name:
/**
* @MyAtribut (2)
*/
Since the attribute compiler doesn't check this, it will insert a
comment in the generated java source that will help the programmer
find the source of the error that Javac will spew out:
c:\mydir\MyClass$Attributes.java:30: Class MyAtribut not found
new MyAtribut (2) // Taken from MyClass.java, line 4
Instead of having to dig into the generated class and try to figure out
what caused the error, you can see that it was in MyClass.java, line 4.
XJavadoc 1.0 had this ability, but it seems to have been lost in 1.2b2.
> It doesn't really matter in the end. Nice work.
Thanks.
> I will like to play with it, and move toward something like this.
>
> Now the next major question is this:
>
> We currently have a need to discover the components that are
> available, so that we can match up the services with the
> implementations. It seems that this will require some sort
> of extension to the classloader so that we can find the
> classes that have attributes attached to them.
I saw this in a Sun forum:
import java.lang.reflect.*;
public class Test1 {
public Test1() {
try {
Class.forName("java.lang.String", true,
ClassLoader.getSystemClassLoader());
} catch (ClassNotFoundException e) {
e.printStackTrace();
}
System.out.println(Test1.class.getClassLoader() ==
ClassLoader.getSystemClassLoader());
displayLoadedClasses(Test1.class.getClassLoader());
}
public static void main (String[] args) {
new Test1();
}
private void displayLoadedClasses(ClassLoader loader) {
try {
Field _classes = ClassLoader.class.getDeclaredField
("classes");
_classes.setAccessible (true);
java.util.Vector _classesVector = (java.util.Vector)
_classes.get (loader);
Class[] result = new Class[_classesVector.size ()];
_classesVector.copyInto (result);
System.out.println(_classesVector);
} catch(Exception ex) {
ex.printStackTrace();
}
}
}
The thing is that there may be no way to get at the classes
that *haven't been loaded yet*:
http://developer.java.sun.com/developer/bugParade/bugs/4061452.html
Bug Id 4061452
Votes 25
Synopsis (reflect) Should provide API for reflection of packages
Category java:classes_lang
Reported Against 1.2, 1.2beta3, 1.1, kestrel-rc1
Release Fixed
State In progress, request for enhancement
Related Bugs 4215635, 4221402, 4295718
Submit Date Jun 25, 1997
Description There is a notable omission in the current reflection
API: packages.
There should be a class java.lang.reflect.Package with methods to
access a named package, and to iterate over the contents of a
package.
This would be particularly useful inside JCK, where we are trying to
verify the
contents of the standard Java packages, making sure that misguided
licencees
do not try and add extra classes into the Java hierarchy.
Another request from xxxxx@xxxxx
Is there any way to get a list of classes in a package?
If not, what is the point of the Package class?
A natural new package method would be:
Class[] Package.getClasses()
which would return a list of all the classes registered
in the Package.
xxxxx@xxxxx 1998-05-08
Evaluation Too late for 1.2, so making this a P5.
xxxxx@xxxxx 1998-06-17
I agree the existing java.lang.Package class is rather lame. It
would make
sense to add a getClasses method to a Package, returning all classes
currently
loaded within the package. Related API changes might be a
getSubPackages method,
a getpackage() method in Class etc.
However, this will not work the miracles that some of the requestors
expect.
In particular, we can only find classes that are loaded; we cannot
plausibly
search the universe (or even the disk, if there is a disk) for
classes within
the package. So I doubt if it addresses JCK needs.
We should consider adding this functionality; but its utility is
limited, so
this must be balanced against the added bloat and run time cost.
xxxxx@xxxxx 2000-03-09
> It is pretty messy to have to iterate over classes, but
> doable if necessary. I would prefer a way to discover
> components that are already loaded on the classpath. That
> may not be possible.
>
> I would be satisfied with a special classloader that had the
> extra method:
>
> Class[] findClasses( Class attribute );
>
> or something like that for class attributes.
OK, how about this:
/**
* Gets a list of all classes with a specific attribute.
* The requirements are:
*
* + The URLClassLoader must either point to...
* ...a local JAR file or
* ...a local directory or
* ...a remote JAR file that will be downloaded in its entirety
and examined
*/
Class[] findClassesWithAttributeType ( URLClassLoader loader, Class
attributeClass );
You can get the URLs used the an URLClassLoader via the getURLs method,
and we can
get all the ugly iteration stuff in one place.
Idea:
How about this. We include in the MANIFEST.mf a list of all classes in
the JAR.
That's it. Just one big list. That is the only packaging requirement.
Then we solve everything else at runtime.
Then we can load classes and index them and so on as needed, but the
packaging
requirements are fixed and dead simple.
> Automatic discovery of components and such will enable things
> like IDE plugins and ANT tools to assist the developer as
> they create and deploy the system.
Just a big list of classes would probably do it. What you
then do with that big list can be left to the application.
It depends on how stable and sophisticated we want the packaging
requirements
to be.
/LS
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Attributes Proof of Concept
Posted by Berin Loritsch <bl...@apache.org>.
Leo Sutic wrote:
> A while ago I suggested that using attributes may be a way out of the
> problems we're having with meta models. The response then was that
> the idea sure seemed nice, but the implementation of the idea sure
> seemed nonexistent.
<snip type="cool stuff and code"/>
I noticed you used XDoclet instead of QDox. Any particular reason why?
It doesn't really matter in the end. Nice work.
I will like to play with it, and move toward something like this.
Now the next major question is this:
We currently have a need to discover the components that are available,
so that we can match up the services with the implementations. It seems
that this will require some sort of extension to the classloader so that
we can find the classes that have attributes attached to them.
It is pretty messy to have to iterate over classes, but doable if necessary.
I would prefer a way to discover components that are already loaded on the
classpath. That may not be possible.
I would be satisfied with a special classloader that had the extra method:
Class[] findClasses( Class attribute );
or something like that for class attributes.
For example, Fortress finds all the services, then finds the associated
components. It does this by extending the JAR packaging mechanism with
the standard "services" JAR extension and a resource that contains a list
of services.
It would work with that approach, but the ultimate best option would to
not have to worry about the packaging criteria.
Currently we have three different ways of discovering components and
services. While that is not horrendous, I would like to evolve toward
one way of discovering what is in the classloader. If the tool can do
it for me, then there is little reason to use the Fortress approach to
extending the packaging requirements or Merlin doing the same.
Phoenix is a bit different because it assumes the assembler knows what
components are available, and the set of components are static.
Automatic discovery of components and such will enable things like IDE
plugins and ANT tools to assist the developer as they create and deploy
the system.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org