You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Peter Donald <pe...@apache.org> on 2002/11/13 04:52:14 UTC
Re: cvs commit: jakarta-avalon-excalibur/configuration build.xml default.properties
Yikes. It looks like we crossed paths.
I am also working on factoring it out which includes supporting just raw
descriptors with dtds/schemas discovered using a semi generic search process
(basically search specified classloader for files that act as a quasi-catalog
and use that to bootstrap the validation process).
Anyways I want to make it able to support all sorts of configration/xml
scenarios. In particular the DTDs in loader/policy/info projects need to be
found by this mechanism and used during validation process.
Anyways I will hold off doing any work on it until you tell me you are done ;)
BTW I was also thinking of moving it into a new project (validator) because it
would no longer be tied to configuration anymore.
--
Cheers,
Peter Donald
*------------------------------------------------------*
| Despite your efforts to be a romantic hero, you will |
| gradually evolve into a postmodern plot device. |
*------------------------------------------------------*
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: cvs commit: jakarta-avalon-excalibur/configuration build.xml default.properties
Posted by Peter Royal <pr...@apache.org>.
On Thursday, November 14, 2002, at 07:21 AM, Peter Donald wrote:
>> would this be a startup
>> process, scan all classloaders for schemas and build a static catalog
>> or build it on demand as a schema is needed?
>
> I was thinking it would build it as in something like the following
>
> //The next line would register all
> //schemas in the current classes classloader
> ValidatorFactory vf =
> new ValidatorFactory( getClass().getClassLoader() );
>
> //get validating content handler
> //schema uri could be null as could the handler
> ContentHandler ch =
> vf.newInstance( "http://relaxng.org/ns/structure/1.0",
> new InputSource( mySchema ),
> myHandler );
>
> ... do xml loading as usual ...
> ... or ...
> ... convert configuration object to dom/sax and pass through ...
>
> The ValidatorFactory would do all lazy caching and stuff like that.
>
> That make sense?
Getting there :) If the ValidatorFactory finds and regsiters all
schemas, what is the 'mySchema' that is passed into the newInstance
method? Would we not pass in a hint indicating what we need a schema
for (required) as well as an optional schema type (which you have).
My gut would be to make this aspect work on SAX streams only, as
wrappers for anything else could be done.
>> 1) schema discovery
>> 2) entity resolver using #1
>> 3) validation API (maybe standardize JARV, or very light wrappers,
>> since it already does just that. perhaps we could do away with
>> specifying the schema-type and autodetect based on namespaces?)
>
> +1
> (though I would allow for both specifying and autodetection)
kewl. i'll be stuck in an airport for many hours tomorrow, plenty of
time to hack.
my only question to you is: what are the autodetection methods that you
are thinking of? I saw some notes in the info package commits (i'll
have to go back and look further), but would that be the jist of them?
-pete
--
peter royal -> proyal@apache.org
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: cvs commit: jakarta-avalon-excalibur/configuration build.xml default.properties
Posted by Peter Donald <pe...@apache.org>.
On Thu, 14 Nov 2002 14:19, Peter Royal wrote:
> kinda confused me here.. one aspect of the validation is auto-discovery
> of the schema files via some predefined rules?
yep.
> would this be a startup
> process, scan all classloaders for schemas and build a static catalog
> or build it on demand as a schema is needed?
I was thinking it would build it as in something like the following
//The next line would register all
//schemas in the current classes classloader
ValidatorFactory vf =
new ValidatorFactory( getClass().getClassLoader() );
//get validating content handler
//schema uri could be null as could the handler
ContentHandler ch =
vf.newInstance( "http://relaxng.org/ns/structure/1.0",
new InputSource( mySchema ),
myHandler );
... do xml loading as usual ...
... or ...
... convert configuration object to dom/sax and pass through ...
The ValidatorFactory would do all lazy caching and stuff like that.
That make sense?
> 1) schema discovery
> 2) entity resolver using #1
> 3) validation API (maybe standardize JARV, or very light wrappers,
> since it already does just that. perhaps we could do away with
> specifying the schema-type and autodetect based on namespaces?)
+1
(though I would allow for both specifying and autodetection)
--
Cheers,
Peter Donald
*------------------------------------------------------*
| "Religion is what the common people see as true, the |
| wise people see as false, and the rulers see as |
| useful" --Seneca |
*------------------------------------------------------*
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: cvs commit: jakarta-avalon-excalibur/configuration build.xml default.properties
Posted by Peter Royal <pr...@apache.org>.
On Tuesday, November 12, 2002, at 10:52 PM, Peter Donald wrote:
> I am also working on factoring it out which includes supporting just
> raw
> descriptors with dtds/schemas discovered using a semi generic search
> process
> (basically search specified classloader for files that act as a
> quasi-catalog
> and use that to bootstrap the validation process).
kinda confused me here.. one aspect of the validation is auto-discovery
of the schema files via some predefined rules? would this be a startup
process, scan all classloaders for schemas and build a static catalog
or build it on demand as a schema is needed?
> Anyways I want to make it able to support all sorts of configration/xml
> scenarios. In particular the DTDs in loader/policy/info projects need
> to be
> found by this mechanism and used during validation process.
so this aspect is a DTD locator? loader/policy/info XML documents will
have DTD reference in them and we'll just have to serve it up, similar
to how phoenix works with the blockinfo files?
> Anyways I will hold off doing any work on it until you tell me you are
> done ;)
ok :) might be a week or so.. some of this will stuff to do while
waiting in airports..
> BTW I was also thinking of moving it into a new project (validator)
> because it
> would no longer be tied to configuration anymore.
there will still need to be a link between the two.. or perhaps
validation can be integrated into configuration building from XML in
certain cases. (ie most things other than phoenix config.xml files that
can't easily conform to a single schema).
but validation can be broken out into a new project with the
configuration integration in a separate package. so i see the following
pieces:
1) schema discovery
2) entity resolver using #1
3) validation API (maybe standardize JARV, or very light wrappers,
since it already does just that. perhaps we could do away with
specifying the schema-type and autodetect based on namespaces?)
4) component configuration validation.
3 and 4 are mostly done.. 1 and 2 need further analysis...
-pete
--
peter royal -> proyal@apache.org
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>