You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Richard Sitze <rs...@us.ibm.com> on 2002/08/24 00:09:55 UTC
[discovery II] Ready for next review
OK Costin, you win :-)
Seriously, the more I played with it, the more I see the value in your
approach. There are some changes (that seems to be a given when I get my
hands on just about anything):
1. ClassInfo extends ResourceInfo.
2. All Discovery classes use Enumeration (it's ugly..)
3. ClassDiscovery & ServiceDiscovery return ClassInfo (not ResourceInfo)
through Enumeration.
4. ServicesDiscovery has changes in semantics. Yours returned
ResourceInfo with the URL & Loader of the META-INF/services/file. I'm
convinced that what you really wanted was the URL and the loader of the
classes themselves, so it uses ClassDiscovery internally for each
'service' found.
5. Services ala Java/Jar document: something like that is in tools
6. Original 'stuff' moved down into tools, and otherwise cleaned up. Most
internal extensions dropped.. you can use the simple tools, or not.
*******************************************
Richard A. Sitze
IBM WebSphere WebServices Development
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [discovery II] Ready for next review
Posted by Richard Sitze <rs...@us.ibm.com>.
Take a look at the code in o.a.c.d.tools.Service and DiscoverClass. I'll
be keeping them up-to-date (they represent a fairly static interface I
want to use at ONE (high) level). They demonstrate usage of the working
classes (in o.a.c.discovery).
The documentation/javadoc if probably fairly accurate in describing what
DiscoverClass DOES.
Regarding keeping up: tell me about it. Took me a week or so to see what
Costin was talking about (an example helped), particularly in how is
should be used (who WANTs that much information, anyway? Just GIVE me
that class, darn it). Clearly the key concepts are ones that are not
apparent from the code, but in how it will be used..
How do I intend to use it?
Consider that I've got the ability to obtain a list of classes, that I can
'query' each class and 'ask' it if it can help me (pass in a param if
needed), apply other selection criteria, and (hopefully) end up with the
'right' class for my needs.
Discovery will not DO that for me, but it will give me the information.
I'll be writing the special-case query/selection code for my needs.
<ras>
*******************************************
Richard A. Sitze
IBM WebSphere WebServices Development
Richard Sitze wrote:
> Nicola,
>
> A brief rundown of current history... after moving from sandbox to
commons
> proper, we decided to refactor the entire scheme... the documentation
> refers to elements that were moved to o.a.c.d.tools. Hefter low-level
> elements are being introduced to o.a.c.discovery, and undergoing
(almost)
> daily refactoring as we work out the design...
I *tried* to follow you two, but you seem to have a prior knowledge of
the needs you are trying to solve with Discover that I still partially
lack.
> there are times when I wish we could just sit down at a table and plow
> through some of this, but the time lag gives everyone time to consider
> ramifactions.
>
> I'd appreciate your comments. You are, of course, welcome to play with
> this, but I wouldn't check it into another project until after the
current
> situation stabilizes somewhat...
That's why I jumped in :-D
> I, like costin, think we are getting close.
It seems so.
> Documentation will be updated after we work a few more things out.
It would be much more easy to partecipate if there were just the main
use-cases with example usage...
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <
mailto:commons-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <
mailto:commons-dev-help@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [discovery II] Ready for next review
Posted by co...@covalent.net.
On Tue, 27 Aug 2002, Nicola Ken Barozzi wrote:
> It would be much more easy to partecipate if there were just the main
> use-cases with example usage...
1. Ant. You want to automatically register tasks. You place fooTasks.jar
and barTasks.jar in ant.home/lib _or_ in your favorite dir and then
use 'embed' and <systempath>. When ProjectHelpers2 starts, it'll use
discovery to find any task and register them automatically. No more
<taskdef> is needed, and all the people are happy because their tasks
behave just like the buildins.
That would involve something like:
Discover.discoverResources( "META-INF/ant.tasks" );
2. Ant. This time with namespaces - if a ns is used, we use it to
construct a name and use discovery to locate all tasks that are registered
for that name.
Discover.discoverResources( "META-INF/ant/" + ns );
3. Modeler. It can dicoverResource( "META-INF/mbeans.xml" ) and load them
automatically.
4. 'Classical' JAXP
5. Commons-logging.
6. JAXP with special feature. Say you want a parser with schema support.
Use Discovery with the JAXP-specified discovery order ( system prop, etc
), but return a list of all found resources. Then for each one you check
if it supports schema. The current jaxp spec returns the first match -
you can't use it to select programatically if multiple parsers are
available.
7. MANIFEST. One thing that is not yet expressed in the API is the ability
to 'discover' informations from the manifest. You could ask for a
spec name and get back the implementation. ( there's a lot of valuable
info in the manifest ).
I know some people like 'explicit' configuration - i.e. explicitely
declare all tasks in ant, explicitely configure the parser, etc. But
in many cases this is just a waste of time and not very user friendly.
Costin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [discovery II] Ready for next review
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Richard Sitze wrote:
> Nicola,
>
> A brief rundown of current history... after moving from sandbox to commons
> proper, we decided to refactor the entire scheme... the documentation
> refers to elements that were moved to o.a.c.d.tools. Hefter low-level
> elements are being introduced to o.a.c.discovery, and undergoing (almost)
> daily refactoring as we work out the design...
I *tried* to follow you two, but you seem to have a prior knowledge of
the needs you are trying to solve with Discover that I still partially lack.
> there are times when I wish we could just sit down at a table and plow
> through some of this, but the time lag gives everyone time to consider
> ramifactions.
>
> I'd appreciate your comments. You are, of course, welcome to play with
> this, but I wouldn't check it into another project until after the current
> situation stabilizes somewhat...
That's why I jumped in :-D
> I, like costin, think we are getting close.
It seems so.
> Documentation will be updated after we work a few more things out.
It would be much more easy to partecipate if there were just the main
use-cases with example usage...
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [discovery II] Ready for next review
Posted by Richard Sitze <rs...@us.ibm.com>.
Nicola,
A brief rundown of current history... after moving from sandbox to commons
proper, we decided to refactor the entire scheme... the documentation
refers to elements that were moved to o.a.c.d.tools. Hefter low-level
elements are being introduced to o.a.c.discovery, and undergoing (almost)
daily refactoring as we work out the design...
there are times when I wish we could just sit down at a table and plow
through some of this, but the time lag gives everyone time to consider
ramifactions.
I'd appreciate your comments. You are, of course, welcome to play with
this, but I wouldn't check it into another project until after the current
situation stabilizes somewhat... I, like costin, think we are getting
close.
Documentation will be updated after we work a few more things out.
<ras>
*******************************************
Richard A. Sitze
IBM WebSphere WebServices Development
costinm@covalent.net wrote:
> On Tue, 27 Aug 2002, Nicola Ken Barozzi wrote:
>
>
>>>>There is a grey area, in that 'class names' are not strictly 'resource
>>>>names' (though that point could be debated for quite a while).
>>>
>>>IMO classes are resources, class names are resources as well.
>>
>>IMV, I just want a
>>
>> Discoverer discoverer = Discovery.getDiscoverer(MyClass.class);
>> List myObjList = discoverer.find(String hint);
>> MyClass MyObj = (MyClass) myObjList.get(0);
>>
>>and when I get the items from the List I cast them to what I
>>*know* comes out of the discovery operation, since I asked for the
>>discoverer that searches for that type (classResult).
>
>
> Well.. First, discover is not about 'hints', but well-defined
> search order and algorithm. It has to support JDK1.1 ( for ant, jaxp,
> common-logging ) - so no List.
Ok, Vector will do ;-)
(List was just 4 the concept)
> It was also discussed that while
> discovering a class is a very important use case, finding general
> resources is also important. ( i.e. ant.tasks, modeler mbeans.xml files,
etc ).
Sure:
Discoverer discoverer=Discovery.getDiscoverer(java.lang.Class.class);
Vector myObjVector=discoverer.find("o.a.c.morphos.MorpherFactory");
Class MyObj = (Class ) myObjVector.get(0);
> Most likely you'll have to be more explicit on what sources and
> order must be used - but a quick shortcut to the very common
> ( system property -> java.home/lib properties -> thread loader -> system
> loader ) search path can be provided. ( I don't think passing
MyClass.class
> is a good idea - what we need is a leaf Loader, and MyClass may be in
the
> system loader ).
Hmmm, ok, then a String.
> You're welcomed to join the discussion - we're getting close (at least
> me and Richard ) and more input and review would be great.
I would like to use it for Morphos, so I'm trying to get a sense of it.
I feel a bit lost without the use-cases you have in mind.
I read from the docs (see where I got the class param):
"
Given a java.lang.Class parameter 'package.Class' that represents a
fundamental service as either an interface, an abstract class (or even a
regular class), find an implementation of that class:
* Look for system property named 'package.Class', the value of which is
the name of an implementation.
* Look for a 'local' property named 'package.Class'...
* Attempt JDK 1.3+ style discovery
* Attempt to load a default implementation
"
I give the first info to tell Discovery what I want the result to be.
Then I ask for it via a hint (can be anything, a classname, a hint,
whatever), that hase sense for the discoverer I got in the first step.
In this case my example makes sense IMHO.
Could you please give me some links to the ones already covered?
Thanks :-)
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <
mailto:commons-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <
mailto:commons-dev-help@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [discovery II] Ready for next review
Posted by Nicola Ken Barozzi <ni...@apache.org>.
costinm@covalent.net wrote:
> On Tue, 27 Aug 2002, Nicola Ken Barozzi wrote:
>
>
>>>>There is a grey area, in that 'class names' are not strictly 'resource
>>>>names' (though that point could be debated for quite a while).
>>>
>>>IMO classes are resources, class names are resources as well.
>>
>>IMV, I just want a
>>
>> Discoverer discoverer = Discovery.getDiscoverer(MyClass.class);
>> List myObjList = discoverer.find(String hint);
>> MyClass MyObj = (MyClass) myObjList.get(0);
>>
>>and when I get the items from the List I cast them to what I
>>*know* comes out of the discovery operation, since I asked for the
>>discoverer that searches for that type (classResult).
>
>
> Well.. First, discover is not about 'hints', but well-defined
> search order and algorithm. It has to support JDK1.1 ( for ant, jaxp,
> common-logging ) - so no List.
Ok, Vector will do ;-)
(List was just 4 the concept)
> It was also discussed that while
> discovering a class is a very important use case, finding general
> resources is also important. ( i.e. ant.tasks, modeler mbeans.xml files, etc ).
Sure:
Discoverer discoverer=Discovery.getDiscoverer(java.lang.Class.class);
Vector myObjVector=discoverer.find("o.a.c.morphos.MorpherFactory");
Class MyObj = (Class ) myObjVector.get(0);
> Most likely you'll have to be more explicit on what sources and
> order must be used - but a quick shortcut to the very common
> ( system property -> java.home/lib properties -> thread loader -> system
> loader ) search path can be provided. ( I don't think passing MyClass.class
> is a good idea - what we need is a leaf Loader, and MyClass may be in the
> system loader ).
Hmmm, ok, then a String.
> You're welcomed to join the discussion - we're getting close (at least
> me and Richard ) and more input and review would be great.
I would like to use it for Morphos, so I'm trying to get a sense of it.
I feel a bit lost without the use-cases you have in mind.
I read from the docs (see where I got the class param):
"
Given a java.lang.Class parameter 'package.Class' that represents a
fundamental service as either an interface, an abstract class (or even a
regular class), find an implementation of that class:
* Look for system property named 'package.Class', the value of which is
the name of an implementation.
* Look for a 'local' property named 'package.Class'...
* Attempt JDK 1.3+ style discovery
* Attempt to load a default implementation
"
I give the first info to tell Discovery what I want the result to be.
Then I ask for it via a hint (can be anything, a classname, a hint,
whatever), that hase sense for the discoverer I got in the first step.
In this case my example makes sense IMHO.
Could you please give me some links to the ones already covered?
Thanks :-)
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [discovery II] Ready for next review
Posted by co...@covalent.net.
On Tue, 27 Aug 2002, Nicola Ken Barozzi wrote:
> >>There is a grey area, in that 'class names' are not strictly 'resource
> >>names' (though that point could be debated for quite a while).
> >
> > IMO classes are resources, class names are resources as well.
>
> IMV, I just want a
>
> Discoverer discoverer = Discovery.getDiscoverer(MyClass.class);
> List myObjList = discoverer.find(String hint);
> MyClass MyObj = (MyClass) myObjList.get(0);
>
> and when I get the items from the List I cast them to what I
> *know* comes out of the discovery operation, since I asked for the
> discoverer that searches for that type (classResult).
Well.. First, discover is not about 'hints', but well-defined
search order and algorithm. It has to support JDK1.1 ( for ant, jaxp,
common-logging ) - so no List. It was also discussed that while
discovering a class is a very important use case, finding general
resources is also important. ( i.e. ant.tasks, modeler mbeans.xml files, etc ).
Most likely you'll have to be more explicit on what sources and
order must be used - but a quick shortcut to the very common
( system property -> java.home/lib properties -> thread loader -> system
loader ) search path can be provided. ( I don't think passing MyClass.class
is a good idea - what we need is a leaf Loader, and MyClass may be in the
system loader ).
You're welcomed to join the discussion - we're getting close (at least
me and Richard ) and more input and review would be great.
Costin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [discovery II] Ready for next review
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Costin Manolache wrote:
> Richard Sitze wrote:
>
>>There is a grey area, in that 'class names' are not strictly 'resource
>>names' (though that point could be debated for quite a while).
>
> IMO classes are resources, class names are resources as well.
IMV, I just want a
Discoverer discoverer = Discovery.getDiscoverer(MyClass.class);
List myObjList = discoverer.find(String hint);
MyClass MyObj = (MyClass) myObjList.get(0);
and when I get the items from the List I cast them to what I
*know* comes out of the discovery operation, since I asked for the
discoverer that searches for that type (classResult).
Just my 2 euros...
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [discovery II] Ready for next review
Posted by Costin Manolache <cm...@yahoo.com>.
Richard Sitze wrote:
> First, the most significant differentiation between ClassInfo and
> ResourceInfo is purely in the type system. I find strong typing useful,
> even when the types have no functional difference (in this case they are).
> I don't find it confusing. I do find the converse confusing: one
> meta-polymorphic type makes the code MUCH more difficult to understand and
> use properly.
What I find confusing is all the code that first creates ResourceInfo
and then copies each one in a new ClassInfo. And the common code
that will do the discovery - and should create the right class.
Maybe an alterntative is to just treat it as a data holder - the
discovery result. The discovery operation is more about finding stuff
in the classpath, and less about intepreting the results ( IMO ).
> 1. ServiceDiscovery performs a three-step process: find resource names,
> find class names (read resource files), find classes. It returns a set of
> classes, NOT a set of services (more on that in a moment).
> 2. ResourceDiscovery performs a one-step process: find a set of resource
> names. While it CAN find a set of .class names, it's not appropriate for
> that use because finding multiple class names doesn't translate to being
> able to LOAD one.
Not sure about the last argument - finding multiple resources does translate
very well into beeing able to load one ( the first or the best fit or the
first that works ). I don't know what problem you see in the LOAD operation.
> 3. ClassDiscovery performs a one-step process: find the ONE URL per class
> loader that corresponds to a given .class.
That's very strange. Why do we want that ? Do you have any use cases for
those things ?
My opinion:
1. ResourceDiscovery is searching the classpath and finds some resources.
The 'resource' is a file in a class loader - it may be read as text or
as a class, and the class may be considered a 'service', but from discovery
perspective we have files in the classpath, with a loader and URL.
2. The caller may use the files as classes. The difference between 'service'
and 'class' is very small - IMO, it's more on how you use that class.
3. We can provide various helpers to use the 'resource' as a service/class -
i.e. create a class, instantiate it, read it as properties, etc. I
personally don't think this is our core function, but you need it.
But regardless of interpretation, I think we are getting closer :-)
> A. Break ServiceDiscovery BACK into a two-step process (much like your
> original): find resource names (using ResourceDiscovery), find class names
> (read resource files). Returns a list of class names (URL & loader are
> meaningless, should return null?) I COULD break this down into two
> separate steps, and build-up... but that may be taking things to far at
> this point.
Well, the URL and loader are very important, when they can be found.
The 'resource' can be used as a class or just a file, and the caller
can choose what to use and how.
I think we have a mismatch in terms:
I call 'discovery' the process of finding something by looking in multiple
sources. So 'ServiceSource' ( META-INF/services ), properties files,
system properties, loader.getResources() are all sources for the discovery
process.
The result of discovery is a list with what was found.
The real meaning of each 'discovery' is only known by the user, we just
provide some helpers (to create classes for example ).
> B. Introduce a PropertyDiscovery (extends ResourceDiscovery), returning
> C. A DefaultDiscovery (or ConstDiscovery) extends ResourceDiscovery,
>
> D. DiscoveryList/Discoverer/ChainDiscovery (extends ResourceDiscovery),
> much like ClassLoaders, lets me build up a list of ResourceDiscovery
> instances { PropertyDiscovery, ServiceDiscovery, DefaultDiscovery }.
>
> E. ClassDiscovery would be able to take a single classname parameter (as
> today) OR a set of classnames via String[], Enumeration (of ResourceInfo),
> or ResourceDiscovery (a parent of DiscoveryList) parameters.
+0
It is very similar with what I have in mind ( we are getting closer, just
use different vocabulary :-).
I can see benefits in having a single hook 'interface' ( Discovery ) that
can be extended by user. I was thinking of 'DiscoverySource' as the base,
and the Discovery using it.
One small request - if we go this route, it would be very nice to keep
the 'base' classes and interfaces in a directory, and all impl classes
in a separate one. I usually like to quickly find the important
interfaces.
> Note that there are TWO types of tasks being performed: 1) Find names,
> and 2) Find classes. Tasks performing (1) should return ResourceInfo, and
> Tasks performing (2) should return ClassInfo. A 'ServiceInfo' type is not
> needed.
+1 on ServiceInfo not needed.
Not convinced about the first part - I think we must find resources, and
then eventually we should interpret them as class names and construct the
classes ( or just let the user do it if he knows better ).
> There is a grey area, in that 'class names' are not strictly 'resource
> names' (though that point could be debated for quite a while).
IMO classes are resources, class names are resources as well.
Costin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [discovery II] Ready for next review
Posted by Richard Sitze <rs...@us.ibm.com>.
First, the most significant differentiation between ClassInfo and
ResourceInfo is purely in the type system. I find strong typing useful,
even when the types have no functional difference (in this case they are).
I don't find it confusing. I do find the converse confusing: one
meta-polymorphic type makes the code MUCH more difficult to understand and
use properly.
With that intro, my mind is going in circles again.... but each time
around I think it's getting closer.
Consider:
1. ServiceDiscovery performs a three-step process: find resource names,
find class names (read resource files), find classes. It returns a set of
classes, NOT a set of services (more on that in a moment).
2. ResourceDiscovery performs a one-step process: find a set of resource
names. While it CAN find a set of .class names, it's not appropriate for
that use because finding multiple class names doesn't translate to being
able to LOAD one.
3. ClassDiscovery performs a one-step process: find the ONE URL per class
loader that corresponds to a given .class.
So, I'm thinking:
A. Break ServiceDiscovery BACK into a two-step process (much like your
original): find resource names (using ResourceDiscovery), find class names
(read resource files). Returns a list of class names (URL & loader are
meaningless, should return null?) I COULD break this down into two
separate steps, and build-up... but that may be taking things to far at
this point.
B. Introduce a PropertyDiscovery (extends ResourceDiscovery), returning
ResourceInfo (URL & loaders are meaningless... starting to think needs a
ClassNameInfo). Returns (a list?) of class names (URL & loader are
meaningless)
C. A DefaultDiscovery (or ConstDiscovery) extends ResourceDiscovery,
provides a 'default' name. Returns a ResourceInfo[1] (?[n]?).
D. DiscoveryList/Discoverer/ChainDiscovery (extends ResourceDiscovery),
much like ClassLoaders, lets me build up a list of ResourceDiscovery
instances { PropertyDiscovery, ServiceDiscovery, DefaultDiscovery }.
E. ClassDiscovery would be able to take a single classname parameter (as
today) OR a set of classnames via String[], Enumeration (of ResourceInfo),
or ResourceDiscovery (a parent of DiscoveryList) parameters.
This provides near-equivalent function to the original DiscoverClass (now
in tools), and I believe it is extendable by users to provide their own
rules. There is another chain of events hiding in there... hmm.
Note that there are TWO types of tasks being performed: 1) Find names,
and 2) Find classes. Tasks performing (1) should return ResourceInfo, and
Tasks performing (2) should return ClassInfo. A 'ServiceInfo' type is not
needed.
There is a grey area, in that 'class names' are not strictly 'resource
names' (though that point could be debated for quite a while).
<ras>
*******************************************
Richard A. Sitze
IBM WebSphere WebServices Development
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [discovery II] Ready for next review
Posted by co...@covalent.net.
On Mon, 26 Aug 2002, Richard Sitze wrote:
> >But simpler is better: Discover -> DiscoverInfo
> Distant memories of a late night are starting to emerge. As it stands:
>
> ClassDiscovery extends ResourceDiscovery
> ClassInfo extends ResourceInfo
>
> I can pass a ClassDiscovery object to a method that is looking for a
> ResourceDiscovery parameter.. and the method will be able to retrieve a
> valid ResourceInfo (alias ClassInfo) [assuming if finds anything].
>
> ServiceDiscovery is broken: it ought to extend ClassDiscovery, NOT
> ResourceDiscovery. For the sake of symetry and possible future growth,
> I'll change/add:
>
> ServiceDiscovery extends ClassDiscovery
> ServiceInfo extends ClassInfo
>
> Finally, if I merge everything, we have no way to grow/extend without
> adding addtional method(s).
Well, its a tradeoff.
For example in commons-logging it seems most people believed it's better
to hardcode all logging levels instead of using a generic log( level, ...)
Do you expect we'll discover a lot of other stuff ? And do you expect
a lot of additional info will be discovered ?
The DicoveryInfo ( or Resource/Class/Service Info ) holds:
- the discovered name
- the location
- the loader ( or discovery source )
- a class name for Class/Service
We can add a generic n/v attribute.
I don't think having an object hierarchy is worth the effort - and it
would be good to know how we'll extend the model before. For example,
assuming we want to add a FooDiscovery/FooInfo - how would the
base class know to create FooInfo instead of ResourceInfo ?
> >I was thinking about the 'policy' stuff - and I was thinking of
> >an alternative ( and simpler ?) solutions:
>
> Funny you should say that... remember my indiscriminate use of a 9-letter
> 'F' word? I was heading this direction without the foundation we now
> have... I had some problems with how to do it, but I think a ResourceInfo
> hierarchy will alleviate those (PropertyInfo w/ PropertyDiscovery & a
> ChainedDiscovery or somesuch.. hmm).
I'm not sure this is an 'F'-word case. The caller doesn't have to
implement any interface, Discovery is just a normal 'java-bean'
or utility class where you set some properties and execute a method.
Regarding the object hierarchy - it would be very nice if you could
explain a bit more how the extension will work and why is it needed.
ChainedDiscovery sounds scarry :-)
Costin
>
> I'll see what I can do moving forward, but it's likely to be slow with
> short bursts.
>
> <ras>
>
> *******************************************
> Richard A. Sitze
> IBM WebSphere WebServices Development
>
>
> On Mon, 26 Aug 2002, Richard Sitze wrote:
>
> > Do you have an opinion on the value of ClassDiscovery being a subclass
> of
> > ResourceDiscovery? This is the only reason why the names of the methods
>
> > are 'findResouces' in ClassDiscovery and ServiceDiscovery. I did it
> that
> > way originally out of habit. I don't see any real value for this,
> > particularly since the return types are different... yuch. I'll fix
> > that.
> >
> > Probably go ahead and move everything into one class, and call that
> > "discover":
> >
> > Discover.resources() - returns Enumeration of ResourceInfo
> > Discover.services() - returns Enumeration of ClassInfo
> > Discover.classes() - returns Enumeration of ClassInfo
> >
> > >A bit asymetric - don't we also need ServiceInfo ?
> >
> > What would it represent that isn't already available from ClassInfo?
>
> If we merge ClassDiscovery, ResourceDiscovery, ServiceDiscovery - then
> probably it make sense to also merge ResourceInfo, ServiceInfo,
> ClassInfo. Some fields will be null where they don't make sense.
>
> My comment was only 'cosmetic' - no extra info, just symetric naming.
> ( i.e. if ClassDiscovery returns ClassInfo, RD -> ResourceInfo, then
> ServiceDiscovery should return ServiceInfo ).
>
> But simpler is better: Discover -> DiscoverInfo
>
> I was thinking about the 'policy' stuff - and I was thinking of
> an alternative ( and simpler ?) solutions:
>
> We could implement the 'policy' order by just adding multiple
> sources to the Discover. Right now we can add loaders as the
> source of discovery, but you can add a 'addPropertySource', etc. The
> behavior - each source will be searched. If a property source is added,
> we'll look for the file and read it if present, etc. The result will be
> an [] ( or Vector ), with ordering given by the order of sources.
>
> For example:
> Discover jaxpDisc=new Discover();
> jaxpDisc.addSystemPropertySource( "javax.xml.parsers...." );
> jaxpDisc.addPropertiesSource(javaHome +"lib/jaxp.properties" );
> jaxpDisc.addLoaderSource( Discovery.getThreadClassLoader() );
> jaxpDisc.addLoaderSource( this.class.getClassLoader() );
>
> DiscoverInfo jaxpInfo[]=jaxpDisc.discoverServices();
>
> ParserFactory=jaxpInfo[0].createClass();
>
> ( alternative: create the factory for each discoverInfo and check if
> it suports schema - or something like that. )
>
>
> Costin
>
>
>
> >
> >
> >
> > *******************************************
> > Richard A. Sitze
> > IBM WebSphere WebServices Development
> >
> >
> > On Fri, 23 Aug 2002, Richard Sitze wrote:
> >
> > > OK Costin, you win :-)
> >
> > That doesn't happen very often, I should celebrate :-)
> >
> > > 1. ClassInfo extends ResourceInfo.
> >
> > You can add the getInstance() helpers in ClassInfo, if
> > you want.
> >
> > Just looking at the code: toClassInfo() seems a bit strange, it should
> > be static or something like that.
> >
> > Maybe to avoid confusions and conversion we can just merge ClassInfo
> into
> > ResourceInfo - or turn ClassInfo into ClassTools that processes
> > ResourceInfos.
> >
> > BTW, also to keep it simpler: I would move
> > ClassDiscovery.findResources() to ResourceDiscovery.findClasses()
> > Same for ServiceDiscovery -> findServices().
> >
> > That's just cosmetics, it doesn't matter too much.
> >
> > > 2. All Discovery classes use Enumeration (it's ugly..)
> >
> > We can return ResourceInfo[]. Easier for the user to manipulate,
> > and we can still preserve the 'lazy' evaluation.
> >
> > I have no problem with Enumeration.
> >
> > > 3. ClassDiscovery & ServiceDiscovery return ClassInfo (not
> > ResourceInfo)
> > > through Enumeration.
> >
> > A bit asymetric - don't we also need ServiceInfo ?
> >
> > > 4. ServicesDiscovery has changes in semantics. Yours returned
> > > ResourceInfo with the URL & Loader of the META-INF/services/file. I'm
>
> > > convinced that what you really wanted was the URL and the loader of
> the
> > > classes themselves, so it uses ClassDiscovery internally for each
> > > 'service' found.
> >
> > Well, if that's what I wanted :-) ...
> >
> > You're right, the Loader and URL for the class itself is what matters -
> > I (wrongly) assumed that the descriptor will be in the same .jar with
> > the classes. This is not allways the case.
> >
> > > 5. Services ala Java/Jar document: something like that is in tools
> >
> > I think I started to understand ManagedProperties. It's an interesting
> > idea, but I'm afraid to even think of tomcat's loader hierarchy ( and
> > the 'reversed' loader order, with child-first ).
> >
> > I still feel this is a bit to complex - but if you need it
> > this way I won't complain.
> >
> > > 6. Original 'stuff' moved down into tools, and otherwise cleaned up.
> > Most
> > > internal extensions dropped.. you can use the simple tools, or not.
> >
> > Great.
> >
> > Costin
> >
> >
> > --
> > To unsubscribe, e-mail: <
> > mailto:commons-dev-unsubscribe@jakarta.apache.org>
> > For additional commands, e-mail: <
> > mailto:commons-dev-help@jakarta.apache.org>
> >
> >
> >
> > --
> > To unsubscribe, e-mail: <
> mailto:commons-dev-unsubscribe@jakarta.apache.org>
> > For additional commands, e-mail: <
> mailto:commons-dev-help@jakarta.apache.org>
> >
> >
>
>
> --
> To unsubscribe, e-mail: <
> mailto:commons-dev-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail: <
> mailto:commons-dev-help@jakarta.apache.org>
>
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [discovery II] Ready for next review
Posted by Richard Sitze <rs...@us.ibm.com>.
>But simpler is better: Discover -> DiscoverInfo
Distant memories of a late night are starting to emerge. As it stands:
ClassDiscovery extends ResourceDiscovery
ClassInfo extends ResourceInfo
I can pass a ClassDiscovery object to a method that is looking for a
ResourceDiscovery parameter.. and the method will be able to retrieve a
valid ResourceInfo (alias ClassInfo) [assuming if finds anything].
ServiceDiscovery is broken: it ought to extend ClassDiscovery, NOT
ResourceDiscovery. For the sake of symetry and possible future growth,
I'll change/add:
ServiceDiscovery extends ClassDiscovery
ServiceInfo extends ClassInfo
Finally, if I merge everything, we have no way to grow/extend without
adding addtional method(s).
I'm going to make the above changes, and drop the idea of merging for now.
>I was thinking about the 'policy' stuff - and I was thinking of
>an alternative ( and simpler ?) solutions:
Funny you should say that... remember my indiscriminate use of a 9-letter
'F' word? I was heading this direction without the foundation we now
have... I had some problems with how to do it, but I think a ResourceInfo
hierarchy will alleviate those (PropertyInfo w/ PropertyDiscovery & a
ChainedDiscovery or somesuch.. hmm).
I'll see what I can do moving forward, but it's likely to be slow with
short bursts.
<ras>
*******************************************
Richard A. Sitze
IBM WebSphere WebServices Development
On Mon, 26 Aug 2002, Richard Sitze wrote:
> Do you have an opinion on the value of ClassDiscovery being a subclass
of
> ResourceDiscovery? This is the only reason why the names of the methods
> are 'findResouces' in ClassDiscovery and ServiceDiscovery. I did it
that
> way originally out of habit. I don't see any real value for this,
> particularly since the return types are different... yuch. I'll fix
> that.
>
> Probably go ahead and move everything into one class, and call that
> "discover":
>
> Discover.resources() - returns Enumeration of ResourceInfo
> Discover.services() - returns Enumeration of ClassInfo
> Discover.classes() - returns Enumeration of ClassInfo
>
> >A bit asymetric - don't we also need ServiceInfo ?
>
> What would it represent that isn't already available from ClassInfo?
If we merge ClassDiscovery, ResourceDiscovery, ServiceDiscovery - then
probably it make sense to also merge ResourceInfo, ServiceInfo,
ClassInfo. Some fields will be null where they don't make sense.
My comment was only 'cosmetic' - no extra info, just symetric naming.
( i.e. if ClassDiscovery returns ClassInfo, RD -> ResourceInfo, then
ServiceDiscovery should return ServiceInfo ).
But simpler is better: Discover -> DiscoverInfo
I was thinking about the 'policy' stuff - and I was thinking of
an alternative ( and simpler ?) solutions:
We could implement the 'policy' order by just adding multiple
sources to the Discover. Right now we can add loaders as the
source of discovery, but you can add a 'addPropertySource', etc. The
behavior - each source will be searched. If a property source is added,
we'll look for the file and read it if present, etc. The result will be
an [] ( or Vector ), with ordering given by the order of sources.
For example:
Discover jaxpDisc=new Discover();
jaxpDisc.addSystemPropertySource( "javax.xml.parsers...." );
jaxpDisc.addPropertiesSource(javaHome +"lib/jaxp.properties" );
jaxpDisc.addLoaderSource( Discovery.getThreadClassLoader() );
jaxpDisc.addLoaderSource( this.class.getClassLoader() );
DiscoverInfo jaxpInfo[]=jaxpDisc.discoverServices();
ParserFactory=jaxpInfo[0].createClass();
( alternative: create the factory for each discoverInfo and check if
it suports schema - or something like that. )
Costin
>
>
>
> *******************************************
> Richard A. Sitze
> IBM WebSphere WebServices Development
>
>
> On Fri, 23 Aug 2002, Richard Sitze wrote:
>
> > OK Costin, you win :-)
>
> That doesn't happen very often, I should celebrate :-)
>
> > 1. ClassInfo extends ResourceInfo.
>
> You can add the getInstance() helpers in ClassInfo, if
> you want.
>
> Just looking at the code: toClassInfo() seems a bit strange, it should
> be static or something like that.
>
> Maybe to avoid confusions and conversion we can just merge ClassInfo
into
> ResourceInfo - or turn ClassInfo into ClassTools that processes
> ResourceInfos.
>
> BTW, also to keep it simpler: I would move
> ClassDiscovery.findResources() to ResourceDiscovery.findClasses()
> Same for ServiceDiscovery -> findServices().
>
> That's just cosmetics, it doesn't matter too much.
>
> > 2. All Discovery classes use Enumeration (it's ugly..)
>
> We can return ResourceInfo[]. Easier for the user to manipulate,
> and we can still preserve the 'lazy' evaluation.
>
> I have no problem with Enumeration.
>
> > 3. ClassDiscovery & ServiceDiscovery return ClassInfo (not
> ResourceInfo)
> > through Enumeration.
>
> A bit asymetric - don't we also need ServiceInfo ?
>
> > 4. ServicesDiscovery has changes in semantics. Yours returned
> > ResourceInfo with the URL & Loader of the META-INF/services/file. I'm
> > convinced that what you really wanted was the URL and the loader of
the
> > classes themselves, so it uses ClassDiscovery internally for each
> > 'service' found.
>
> Well, if that's what I wanted :-) ...
>
> You're right, the Loader and URL for the class itself is what matters -
> I (wrongly) assumed that the descriptor will be in the same .jar with
> the classes. This is not allways the case.
>
> > 5. Services ala Java/Jar document: something like that is in tools
>
> I think I started to understand ManagedProperties. It's an interesting
> idea, but I'm afraid to even think of tomcat's loader hierarchy ( and
> the 'reversed' loader order, with child-first ).
>
> I still feel this is a bit to complex - but if you need it
> this way I won't complain.
>
> > 6. Original 'stuff' moved down into tools, and otherwise cleaned up.
> Most
> > internal extensions dropped.. you can use the simple tools, or not.
>
> Great.
>
> Costin
>
>
> --
> To unsubscribe, e-mail: <
> mailto:commons-dev-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail: <
> mailto:commons-dev-help@jakarta.apache.org>
>
>
>
> --
> To unsubscribe, e-mail: <
mailto:commons-dev-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail: <
mailto:commons-dev-help@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <
mailto:commons-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <
mailto:commons-dev-help@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [discovery II] Ready for next review
Posted by co...@covalent.net.
On Mon, 26 Aug 2002, Richard Sitze wrote:
> Do you have an opinion on the value of ClassDiscovery being a subclass of
> ResourceDiscovery? This is the only reason why the names of the methods
> are 'findResouces' in ClassDiscovery and ServiceDiscovery. I did it that
> way originally out of habit. I don't see any real value for this,
> particularly since the return types are different... yuch. I'll fix
> that.
>
> Probably go ahead and move everything into one class, and call that
> "discover":
>
> Discover.resources() - returns Enumeration of ResourceInfo
> Discover.services() - returns Enumeration of ClassInfo
> Discover.classes() - returns Enumeration of ClassInfo
>
> >A bit asymetric - don't we also need ServiceInfo ?
>
> What would it represent that isn't already available from ClassInfo?
If we merge ClassDiscovery, ResourceDiscovery, ServiceDiscovery - then
probably it make sense to also merge ResourceInfo, ServiceInfo,
ClassInfo. Some fields will be null where they don't make sense.
My comment was only 'cosmetic' - no extra info, just symetric naming.
( i.e. if ClassDiscovery returns ClassInfo, RD -> ResourceInfo, then
ServiceDiscovery should return ServiceInfo ).
But simpler is better: Discover -> DiscoverInfo
I was thinking about the 'policy' stuff - and I was thinking of
an alternative ( and simpler ?) solutions:
We could implement the 'policy' order by just adding multiple
sources to the Discover. Right now we can add loaders as the
source of discovery, but you can add a 'addPropertySource', etc. The
behavior - each source will be searched. If a property source is added,
we'll look for the file and read it if present, etc. The result will be
an [] ( or Vector ), with ordering given by the order of sources.
For example:
Discover jaxpDisc=new Discover();
jaxpDisc.addSystemPropertySource( "javax.xml.parsers...." );
jaxpDisc.addPropertiesSource(javaHome +"lib/jaxp.properties" );
jaxpDisc.addLoaderSource( Discovery.getThreadClassLoader() );
jaxpDisc.addLoaderSource( this.class.getClassLoader() );
DiscoverInfo jaxpInfo[]=jaxpDisc.discoverServices();
ParserFactory=jaxpInfo[0].createClass();
( alternative: create the factory for each discoverInfo and check if
it suports schema - or something like that. )
Costin
>
>
>
> *******************************************
> Richard A. Sitze
> IBM WebSphere WebServices Development
>
>
> On Fri, 23 Aug 2002, Richard Sitze wrote:
>
> > OK Costin, you win :-)
>
> That doesn't happen very often, I should celebrate :-)
>
> > 1. ClassInfo extends ResourceInfo.
>
> You can add the getInstance() helpers in ClassInfo, if
> you want.
>
> Just looking at the code: toClassInfo() seems a bit strange, it should
> be static or something like that.
>
> Maybe to avoid confusions and conversion we can just merge ClassInfo into
> ResourceInfo - or turn ClassInfo into ClassTools that processes
> ResourceInfos.
>
> BTW, also to keep it simpler: I would move
> ClassDiscovery.findResources() to ResourceDiscovery.findClasses()
> Same for ServiceDiscovery -> findServices().
>
> That's just cosmetics, it doesn't matter too much.
>
> > 2. All Discovery classes use Enumeration (it's ugly..)
>
> We can return ResourceInfo[]. Easier for the user to manipulate,
> and we can still preserve the 'lazy' evaluation.
>
> I have no problem with Enumeration.
>
> > 3. ClassDiscovery & ServiceDiscovery return ClassInfo (not
> ResourceInfo)
> > through Enumeration.
>
> A bit asymetric - don't we also need ServiceInfo ?
>
> > 4. ServicesDiscovery has changes in semantics. Yours returned
> > ResourceInfo with the URL & Loader of the META-INF/services/file. I'm
> > convinced that what you really wanted was the URL and the loader of the
> > classes themselves, so it uses ClassDiscovery internally for each
> > 'service' found.
>
> Well, if that's what I wanted :-) ...
>
> You're right, the Loader and URL for the class itself is what matters -
> I (wrongly) assumed that the descriptor will be in the same .jar with
> the classes. This is not allways the case.
>
> > 5. Services ala Java/Jar document: something like that is in tools
>
> I think I started to understand ManagedProperties. It's an interesting
> idea, but I'm afraid to even think of tomcat's loader hierarchy ( and
> the 'reversed' loader order, with child-first ).
>
> I still feel this is a bit to complex - but if you need it
> this way I won't complain.
>
> > 6. Original 'stuff' moved down into tools, and otherwise cleaned up.
> Most
> > internal extensions dropped.. you can use the simple tools, or not.
>
> Great.
>
> Costin
>
>
> --
> To unsubscribe, e-mail: <
> mailto:commons-dev-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail: <
> mailto:commons-dev-help@jakarta.apache.org>
>
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [discovery II] Ready for next review
Posted by Richard Sitze <rs...@us.ibm.com>.
Do you have an opinion on the value of ClassDiscovery being a subclass of
ResourceDiscovery? This is the only reason why the names of the methods
are 'findResouces' in ClassDiscovery and ServiceDiscovery. I did it that
way originally out of habit. I don't see any real value for this,
particularly since the return types are different... yuch. I'll fix
that.
Probably go ahead and move everything into one class, and call that
"discover":
Discover.resources() - returns Enumeration of ResourceInfo
Discover.services() - returns Enumeration of ClassInfo
Discover.classes() - returns Enumeration of ClassInfo
>A bit asymetric - don't we also need ServiceInfo ?
What would it represent that isn't already available from ClassInfo?
*******************************************
Richard A. Sitze
IBM WebSphere WebServices Development
On Fri, 23 Aug 2002, Richard Sitze wrote:
> OK Costin, you win :-)
That doesn't happen very often, I should celebrate :-)
> 1. ClassInfo extends ResourceInfo.
You can add the getInstance() helpers in ClassInfo, if
you want.
Just looking at the code: toClassInfo() seems a bit strange, it should
be static or something like that.
Maybe to avoid confusions and conversion we can just merge ClassInfo into
ResourceInfo - or turn ClassInfo into ClassTools that processes
ResourceInfos.
BTW, also to keep it simpler: I would move
ClassDiscovery.findResources() to ResourceDiscovery.findClasses()
Same for ServiceDiscovery -> findServices().
That's just cosmetics, it doesn't matter too much.
> 2. All Discovery classes use Enumeration (it's ugly..)
We can return ResourceInfo[]. Easier for the user to manipulate,
and we can still preserve the 'lazy' evaluation.
I have no problem with Enumeration.
> 3. ClassDiscovery & ServiceDiscovery return ClassInfo (not
ResourceInfo)
> through Enumeration.
A bit asymetric - don't we also need ServiceInfo ?
> 4. ServicesDiscovery has changes in semantics. Yours returned
> ResourceInfo with the URL & Loader of the META-INF/services/file. I'm
> convinced that what you really wanted was the URL and the loader of the
> classes themselves, so it uses ClassDiscovery internally for each
> 'service' found.
Well, if that's what I wanted :-) ...
You're right, the Loader and URL for the class itself is what matters -
I (wrongly) assumed that the descriptor will be in the same .jar with
the classes. This is not allways the case.
> 5. Services ala Java/Jar document: something like that is in tools
I think I started to understand ManagedProperties. It's an interesting
idea, but I'm afraid to even think of tomcat's loader hierarchy ( and
the 'reversed' loader order, with child-first ).
I still feel this is a bit to complex - but if you need it
this way I won't complain.
> 6. Original 'stuff' moved down into tools, and otherwise cleaned up.
Most
> internal extensions dropped.. you can use the simple tools, or not.
Great.
Costin
--
To unsubscribe, e-mail: <
mailto:commons-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <
mailto:commons-dev-help@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [discovery II] Ready for next review
Posted by co...@covalent.net.
On Fri, 23 Aug 2002, Richard Sitze wrote:
> OK Costin, you win :-)
That doesn't happen very often, I should celebrate :-)
> 1. ClassInfo extends ResourceInfo.
You can add the getInstance() helpers in ClassInfo, if
you want.
Just looking at the code: toClassInfo() seems a bit strange, it should
be static or something like that.
Maybe to avoid confusions and conversion we can just merge ClassInfo into
ResourceInfo - or turn ClassInfo into ClassTools that processes
ResourceInfos.
BTW, also to keep it simpler: I would move
ClassDiscovery.findResources() to ResourceDiscovery.findClasses()
Same for ServiceDiscovery -> findServices().
That's just cosmetics, it doesn't matter too much.
> 2. All Discovery classes use Enumeration (it's ugly..)
We can return ResourceInfo[]. Easier for the user to manipulate,
and we can still preserve the 'lazy' evaluation.
I have no problem with Enumeration.
> 3. ClassDiscovery & ServiceDiscovery return ClassInfo (not ResourceInfo)
> through Enumeration.
A bit asymetric - don't we also need ServiceInfo ?
> 4. ServicesDiscovery has changes in semantics. Yours returned
> ResourceInfo with the URL & Loader of the META-INF/services/file. I'm
> convinced that what you really wanted was the URL and the loader of the
> classes themselves, so it uses ClassDiscovery internally for each
> 'service' found.
Well, if that's what I wanted :-) ...
You're right, the Loader and URL for the class itself is what matters -
I (wrongly) assumed that the descriptor will be in the same .jar with
the classes. This is not allways the case.
> 5. Services ala Java/Jar document: something like that is in tools
I think I started to understand ManagedProperties. It's an interesting
idea, but I'm afraid to even think of tomcat's loader hierarchy ( and
the 'reversed' loader order, with child-first ).
I still feel this is a bit to complex - but if you need it
this way I won't complain.
> 6. Original 'stuff' moved down into tools, and otherwise cleaned up. Most
> internal extensions dropped.. you can use the simple tools, or not.
Great.
Costin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [discovery II] Ready for next review
Posted by co...@covalent.net.
Extra notes:
- for the ant task - I'll move it to ant/proposals/embed - and
start playing with task discovery.
- jdk stuff - for now we can just use the jdk1.2 code. You may
take a look at jakarta-tomcat/src/share/org/apache/tomcat/util/compat/ -
there is already a lot of implementation for the 1.1 wrappers and
it follows the same patterns. It may be a good idea to move all
the implementation here ( I know it's a different problem, but
we'll probably need most of the code anyway to support getResources()).
Costin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>