cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marc Portier <...@outerthought.org>
Subject Re: deploying and updating a cocoon site
Date Wed, 21 May 2003 13:58:59 GMT


Geoff Howard wrote:
> At 07:19 AM 5/21/2003, you wrote:
> 
>> Le Mercredi, 21 mai 2003, à 13:07 Europe/Zurich, Giacomo Pati a écrit :
>>
>>> ...Sure, but the XConfTool files are much more compact and readable 
>>> to average
>>> people as a hole xslt file. We build hole deployable Cocoon apps 
>>> using that
>>> instead of xslt's.
>>
>>
>> I see your point - if XConfTool is sufficient for one's need (or one 
>> wants to expand it), all the better! It is certainly easier to grasp 
>> than XSLT if one does not know either of them.
>>
>> What would be useful though (and what I was suggesting to Miles) is an 
>> easy way to plug "configuration patches" in the build process through 
>> local.build.properties, I don't think this is possible now.
>>
>> -Bertrand
> 
> 
> This is exactly what I started working on last night.  You can indeed 
> either
> add or replace nodes with XconfTool, and it works well.  There was a 
> recent change
> which allowed modifying web.xml in this way as well, and my first step has
> been to add a ".xweb" file to the database and hsql block that adds the
> driver info at build time.  Next step will be to modify config for uploads.
> 

nice

> Anyone see a problem with this?  As this is not an architectural level 
> change,
> I'm hoping to sneak this in before 2.1 reaches beta.
> 

sharing hopes

> By the way, at the moment I'm stuck on the fact that the xconf tool (or 
> the xml
> library it calls actually) is not trying to resolve the DTD for web.xml, 
> and

not?
I recon he _is_ trying and because he fails you are seeing the 
problem? or else I'm stuck with double negations in the english 
language

> I'm not quite clear how to get it to use an entity catalog (though David 
> C. has
> given me a hint that I'm not yet sure how to apply).
> 

normally the catalog resolving is something to set on the level 
of the xml parser...

DocumentBuilder builder =....
followed by
builder.setEntityResolver(...);

the org.xml.sax.EntityResolver argument to pass can be the
org.apache.xml.resolver.tools.CatalogResolver implementation from 
the resolver-***.jar which is the one from xml-commons if not 
mistaking. (see http://xml.apache.org/commons/, I'm afraid you'll 
need to get it and build the docs locally, cause I can't find 
anything else then the docbook explanation in from cvs 
http://cvs.apache.org/viewcvs.cgi/xml-commons/src/documentation/content/xdocs/components/resolver/resolver-article.xml?rev=1.1&content-type=text/vnd.viewcvs-markup)

in the docbook I found (apart from great background reading):


[1] code snippet
import org.apache.xml.resolver.tools.CatalogResolver;
...
     CatalogResolver cr = new CatalogResolver();
...
     yourParser.setEntityResolver(cr)


[2] additionally you will need to have some
CatalogManager.properties in your classpath
example:
#CatalogManager.properties
verbosity=1
relative-catalogs=yes
# Always use semicolons in this list
catalogs=./xcatalog;/share/doctypes/catalog;/share/doctypes/xcatalog
prefer=public
static-catalog=yes
allow-oasis-xml-catalog-pi=yes
catalog-class-name=org.apache.xml.resolver.Resolver


[3]and the catalog itself of course
example:
<catalog xmlns="urn:oasis:names:tc:entity:xmlns:xml:catalog">
<public publicId="-//Example//DTD Example V1.0//EN"
         uri="example.dtd"/>
</catalog>


let me know if this is not helping you enough
(I know for sure David C is the real experienced one in this field)

> Geoff
> 

regards,
-marc=
-- 
Marc Portier                            http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at              http://radio.weblogs.com/0116284/
mpo@outerthought.org                              mpo@apache.org


Mime
View raw message