You are viewing a plain text version of this content. The canonical link for it is here.
Posted to svn@forrest.apache.org by rg...@apache.org on 2005/04/21 20:56:27 UTC
svn commit: r164099 -
/forrest/trunk/plugins/org.apache.forrest.plugin.input.projectInfo/status.xml
Author: rgardler
Date: Thu Apr 21 11:56:27 2005
New Revision: 164099
URL: http://svn.apache.org/viewcvs?rev=164099&view=rev
Log:
[WORKAROUND] use URL for DTD as plugin is fails to find it using the catalogs
Modified:
forrest/trunk/plugins/org.apache.forrest.plugin.input.projectInfo/status.xml
Modified: forrest/trunk/plugins/org.apache.forrest.plugin.input.projectInfo/status.xml
URL: http://svn.apache.org/viewcvs/forrest/trunk/plugins/org.apache.forrest.plugin.input.projectInfo/status.xml?rev=164099&r1=164098&r2=164099&view=diff
==============================================================================
--- forrest/trunk/plugins/org.apache.forrest.plugin.input.projectInfo/status.xml (original)
+++ forrest/trunk/plugins/org.apache.forrest.plugin.input.projectInfo/status.xml Thu Apr 21 11:56:27 2005
@@ -15,7 +15,7 @@
See the License for the specific language governing permissions and
limitations under the License.
-->
-<!DOCTYPE status PUBLIC "-//APACHE//DTD Status V1.3//EN" "status-v13.dtd">
+<!DOCTYPE status PUBLIC "-//APACHE//DTD Status V1.3//EN" "http://forrest.apache.org/dtd/status-v13.dtd">
<status>
<developers>
Re: svn commit: r164099 - /forrest/trunk/plugins/org.apache.forrest.plugin.input.projectInfo/status.xml)
Posted by David Crossley <cr...@apache.org>.
Fri, Apr 22, 2005 at 08:26:51PM +1000, David Crossley wrote:
> Ross Gardler wrote:
> > David Crossley wrote:
> > >I don't understand what you mean Ross. It already works for me,
> > >the catalog entity resolver finds the local "status DTD".
> > >
> > >That can be proved that by changing the publicIdentifier
> > >in status.xml to be deliberately broken, then it fails
> > >as it should,
> > >e.g. ... PUBLIC "-//APACHE//DTD Status Foo-Bust V1.3//EN"
> >
> > Well it isn't working for me. Forrest appears to not be resolving the
> > catalogs since it is looking in the local directory for the DTD.
> >
> > This happens for the projectInfo, OpenOffice.org and simplified-docbook
> > plugins.
> >
> > Any ideas?
>
> How are you invoking forrest?
> If it is in the plugins directory using
> 'forrest/tools/ant/bin/ant test'
> then did you remember the recent discussion
> about the system Ant libs missing resolver.jar
> http://forrest.apache.org/0.7/docs/howto/howto-buildPlugin.html#ant
>
> --David
Re: failure of new entity resolver on some OS
Posted by Norman Walsh <nd...@nwalsh.com>.
/ George Cristian Bina <ge...@sync.ro> was heard to say:
| The problem is that a file URL needs to either specify no host or
| specify it as empty, that is you can have either
| file:/path
| or
| file:///path
| Otherwise if you write file://c:/etc then c will be interpreated as
| host and thus the unknown host exception.
Bleh. Ok, I'll go through the code and take steps to make sure that
the file:// form isn't generated where base URIs and catalog file
names are manipulated.
I'm on vacation[1] starting, well, to be honest, as soon as I hit send
on this message :-), so I won't be able to commit any fixes before
19/20 May. Sorry for the delay.
Be seeing you,
norm
[1] http://norman.walsh.name/2005/itinerary/05-09-vacation
--
Norman.Walsh@Sun.COM / XML Standards Architect / Sun Microsystems, Inc.
NOTICE: This email message is for the sole use of the intended
recipient(s) and may contain confidential and privileged information.
Any unauthorized review, use, disclosure or distribution is prohibited.
If you are not the intended recipient, please contact the sender by
reply email and destroy all copies of the original message.
Re: failure of new entity resolver on some OS
Posted by George Cristian Bina <ge...@sync.ro>.
Hi Norm,
The problem is that a file URL needs to either specify no host or
specify it as empty, that is you can have either
file:/path
or
file:///path
Otherwise if you write file://c:/etc then c will be interpreated as host
and thus the unknown host exception.
Hope that helps,
George
------------------------
http://www.oxygenxml.com
Norman Walsh wrote:
> / David Crossley <cr...@apache.org> was heard to say:
> | Here are the unsuccessful startup messages on Win ...
> | (using Windows XP SP2 + Cygwin)
>
> What is in your CatalogManager.properties file?
>
> | ------
> | Parse catalog:
> | file:/D:/openSource/forrest/main/webapp/resources/schema/catalog.
> | xcat
> | Loading catalog:
> | file:/D:/openSource/forrest/main/webapp/resources/schema/catalo
> | g.xcat
> | Default BASE:
> | file://D:/D:/openSource/forrest/main/webapp/resources/schema/catal
> | og.xcat
>
> That looks really odd.
>
> | Parse text/plain catalog on input stream
> | No CatalogReader for MIME type: text/plain
>
> Why is there an extra space in there? How did it decide the media type
> was " text/plain"?
>
> | When we revert to the old resolver.jar everything works
> | on both platforms.
>
> I can't reproduce the problems your experience, though I am
> experiencing my own baffling problems.
>
> C:\Documents and Settings\Norman Walsh\Java\tests\resolver>java -cp ..\..;..\..\
> resolver.jar org.apache.xml.resolver.apps.xread test1.xml
> Parse catalog: catalogs/main.catalog
> Loading catalog: catalogs/main.catalog
> Default BASE: file://C:/Documents and Settings/Norman Walsh/Java/tests/resolver/
> catalogs/main.catalog
> pcf: file://C:/Documents and Settings/Norman Walsh/Java/tests/resolver/catalogs/
> main.catalog
> java.net.UnknownHostException: C
> at java.net.PlainSocketImpl.connect(Unknown Source)
> at java.net.Socket.connect(Unknown Source)
> at java.net.Socket.connect(Unknown Source)
> at sun.net.NetworkClient.doConnect(Unknown Source)
> at sun.net.NetworkClient.openServer(Unknown Source)
> at sun.net.ftp.FtpClient.openServer(Unknown Source)
> at sun.net.ftp.FtpClient.<init>(Unknown Source)
> at sun.net.www.protocol.ftp.FtpURLConnection.connect(Unknown Source)
> at sun.net.www.protocol.ftp.FtpURLConnection.getInputStream(Unknown Sour
> ce)
> at java.net.URL.openStream(Unknown Source)
> at org.apache.xml.resolver.Catalog.parseCatalogFile(Unknown Source)
>
>
> The "pcf:" debugging message above convinces me that I've got a file: URI
> in a URL object and I called
>
> inStream = new DataInputStream(base.openStream());
>
> and it failed with
>
> java.net.UnknownHostException: C
>
> which seems completely bogus to me.
>
> Any Windows users out there have a clue?
>
> Be seeing you,
> norm
>
Re: failure of new entity resolver on some OS
Posted by David Crossley <cr...@apache.org>.
Norman Walsh wrote:
> / David Crossley <cr...@apache.org> was heard to say:
> | Here are the unsuccessful startup messages on Win ...
> | (using Windows XP SP2 + Cygwin)
>
> What is in your CatalogManager.properties file?
Not much at all. We load the main catalogs via programmatic
mechanisms when the app starts. We only have a CatalogManager.properties
file to silence the message about it not being found when the
parser starts.
Let me reinforce one major point. Everything worked beautifully
with the current release of the resolver. When we tried this
new version, a Windows user is now reporting these problems.
> | ------
> | Parse catalog:
> | file:/D:/openSource/forrest/main/webapp/resources/schema/catalog.
> | xcat
> | Loading catalog:
> | file:/D:/openSource/forrest/main/webapp/resources/schema/catalo
> | g.xcat
> | Default BASE:
> | file://D:/D:/openSource/forrest/main/webapp/resources/schema/catal
> | og.xcat
>
> That looks really odd.
Yes. In that catalog.xcat we do not declare a "BASE". So perhaps
it is the construction of the "Default BASE" URI on Windows that
is failing. No such problems on UNIX.
As George said, it needs to be either
file:/D:/openSource/...
or
file:///D:/openSource/...
> | Parse text/plain catalog on input stream
> | No CatalogReader for MIME type: text/plain
>
> Why is there an extra space in there? How did it decide the media type
> was " text/plain"?
Dunno. Probably a side-effect of the broken URI.
> | When we revert to the old resolver.jar everything works
> | on both platforms.
>
> I can't reproduce the problems your experience, though I am
> experiencing my own baffling problems.
Your issues below sound very similar.
--David
> C:\Documents and Settings\Norman Walsh\Java\tests\resolver>java -cp ..\..;..\..\
> resolver.jar org.apache.xml.resolver.apps.xread test1.xml
> Parse catalog: catalogs/main.catalog
> Loading catalog: catalogs/main.catalog
> Default BASE: file://C:/Documents and Settings/Norman Walsh/Java/tests/resolver/
> catalogs/main.catalog
> pcf: file://C:/Documents and Settings/Norman Walsh/Java/tests/resolver/catalogs/
> main.catalog
> java.net.UnknownHostException: C
> at java.net.PlainSocketImpl.connect(Unknown Source)
> at java.net.Socket.connect(Unknown Source)
> at java.net.Socket.connect(Unknown Source)
> at sun.net.NetworkClient.doConnect(Unknown Source)
> at sun.net.NetworkClient.openServer(Unknown Source)
> at sun.net.ftp.FtpClient.openServer(Unknown Source)
> at sun.net.ftp.FtpClient.<init>(Unknown Source)
> at sun.net.www.protocol.ftp.FtpURLConnection.connect(Unknown Source)
> at sun.net.www.protocol.ftp.FtpURLConnection.getInputStream(Unknown Sour
> ce)
> at java.net.URL.openStream(Unknown Source)
> at org.apache.xml.resolver.Catalog.parseCatalogFile(Unknown Source)
>
>
> The "pcf:" debugging message above convinces me that I've got a file: URI
> in a URL object and I called
>
> inStream = new DataInputStream(base.openStream());
>
> and it failed with
>
> java.net.UnknownHostException: C
>
> which seems completely bogus to me.
>
> Any Windows users out there have a clue?
>
> Be seeing you,
> norm
>
> --
> Norman.Walsh@Sun.COM / XML Standards Architect / Sun Microsystems, Inc.
> NOTICE: This email message is for the sole use of the intended
> recipient(s) and may contain confidential and privileged information.
> Any unauthorized review, use, disclosure or distribution is prohibited.
> If you are not the intended recipient, please contact the sender by
> reply email and destroy all copies of the original message.
Re: failure of new entity resolver on some OS
Posted by Norman Walsh <nd...@nwalsh.com>.
/ David Crossley <cr...@apache.org> was heard to say:
| Here are the unsuccessful startup messages on Win ...
| (using Windows XP SP2 + Cygwin)
What is in your CatalogManager.properties file?
| ------
| Parse catalog:
| file:/D:/openSource/forrest/main/webapp/resources/schema/catalog.
| xcat
| Loading catalog:
| file:/D:/openSource/forrest/main/webapp/resources/schema/catalo
| g.xcat
| Default BASE:
| file://D:/D:/openSource/forrest/main/webapp/resources/schema/catal
| og.xcat
That looks really odd.
| Parse text/plain catalog on input stream
| No CatalogReader for MIME type: text/plain
Why is there an extra space in there? How did it decide the media type
was " text/plain"?
| When we revert to the old resolver.jar everything works
| on both platforms.
I can't reproduce the problems your experience, though I am
experiencing my own baffling problems.
C:\Documents and Settings\Norman Walsh\Java\tests\resolver>java -cp ..\..;..\..\
resolver.jar org.apache.xml.resolver.apps.xread test1.xml
Parse catalog: catalogs/main.catalog
Loading catalog: catalogs/main.catalog
Default BASE: file://C:/Documents and Settings/Norman Walsh/Java/tests/resolver/
catalogs/main.catalog
pcf: file://C:/Documents and Settings/Norman Walsh/Java/tests/resolver/catalogs/
main.catalog
java.net.UnknownHostException: C
at java.net.PlainSocketImpl.connect(Unknown Source)
at java.net.Socket.connect(Unknown Source)
at java.net.Socket.connect(Unknown Source)
at sun.net.NetworkClient.doConnect(Unknown Source)
at sun.net.NetworkClient.openServer(Unknown Source)
at sun.net.ftp.FtpClient.openServer(Unknown Source)
at sun.net.ftp.FtpClient.<init>(Unknown Source)
at sun.net.www.protocol.ftp.FtpURLConnection.connect(Unknown Source)
at sun.net.www.protocol.ftp.FtpURLConnection.getInputStream(Unknown Sour
ce)
at java.net.URL.openStream(Unknown Source)
at org.apache.xml.resolver.Catalog.parseCatalogFile(Unknown Source)
The "pcf:" debugging message above convinces me that I've got a file: URI
in a URL object and I called
inStream = new DataInputStream(base.openStream());
and it failed with
java.net.UnknownHostException: C
which seems completely bogus to me.
Any Windows users out there have a clue?
Be seeing you,
norm
--
Norman.Walsh@Sun.COM / XML Standards Architect / Sun Microsystems, Inc.
NOTICE: This email message is for the sole use of the intended
recipient(s) and may contain confidential and privileged information.
Any unauthorized review, use, disclosure or distribution is prohibited.
If you are not the intended recipient, please contact the sender by
reply email and destroy all copies of the original message.
failure of new entity resolver on some OS
Posted by David Crossley <cr...@apache.org>.
I recently added the new resolver to Apache Forrest.
It works beautifully on UNIX, but one of our developers
uses Win where it is a total failure.
Here are the messages when the resolver starts sucessfully
on UNIX ...
------
Parse catalog: file:/svn/asf/forrest/main/webapp/resources/schema/catalog.xcat
Loading catalog: file:/svn/asf/forrest/main/webapp/resources/schema/catalog.xcat
Default BASE: file:/svn/asf/forrest/main/webapp/resources/schema/catalog.xcat
override: yes
OVERRIDE: yes
nextCatalog: catalog.forrest.xcat
CATALOG: file:/svn/asf/forrest/main/webapp/resources/schema/catalog.forrest.xcat
nextCatalog: w3c-dtd/catalog.xcat
CATALOG: file:/svn/asf/forrest/main/webapp/resources/schema/w3c-dtd/catalog.xcat
nextCatalog: docbook/catalog.xcat
CATALOG: file:/svn/asf/forrest/main/webapp/resources/schema/docbook/catalog.xcat
nextCatalog: sdocbook/catalog.xcat
CATALOG: file:/svn/asf/forrest/main/webapp/resources/schema/sdocbook/catalog.xcat
nextCatalog: open-office/catalog.xcat
CATALOG: file:/svn/asf/forrest/main/webapp/resources/schema/open-office/catalog.xcat
------
Here are the unsuccessful startup messages on Win ...
(using Windows XP SP2 + Cygwin)
------
Parse catalog:
file:/D:/openSource/forrest/main/webapp/resources/schema/catalog.
xcat
Loading catalog:
file:/D:/openSource/forrest/main/webapp/resources/schema/catalo
g.xcat
Default BASE:
file://D:/D:/openSource/forrest/main/webapp/resources/schema/catal
og.xcat
Parse text/plain catalog on input stream
No CatalogReader for MIME type: text/plain
------
When we revert to the old resolver.jar everything works
on both platforms.
--David
Re: possible entity resolver failure (Was: svn commit: r164099)
Posted by David Crossley <cr...@apache.org>.
Ross Gardler wrote:
> David Crossley wrote:
> >
> >Recently i upgraded the entity resolver jar to a new
> >pre-release. Today i reverted that, so lets see if that
> >helps you.
>
> Bingo!!! That does the trick.
>
> For reference I am using Windows XP SP2 + Cygwin
>
> Thanks for your help.
Oh, a bug. Sorry that it took us so long to find that.
I will take the bug report over to Apache XML Commons.
--David
Re: possible entity resolver failure (Was: svn commit: r164099)
Posted by Ross Gardler <rg...@apache.org>.
David Crossley wrote:
> Ross Gardler wrote:
>
>>David Crossley wrote:
>>
>>>Ross Gardler wrote:
>
> [ snip ]
>
>>>>I just verified I was at the latest release of Forrest, and did a clean
>>>>build (somehow I always forget to do that). But no change.
>
>
> I double-checked again :-) that i have no un-committed files.
>
> Perhaps you should try a complete fresh checkout.
> However before you do that ...
>
> Recently i upgraded the entity resolver jar to a new
> pre-release. Today i reverted that, so lets see if that
> helps you.
Bingo!!! That does the trick.
For reference I am using Windows XP SP2 + Cygwin
Thanks for your help.
Ross
Re: possible entity resolver failure (Was: svn commit: r164099)
Posted by David Crossley <cr...@apache.org>.
Ross Gardler wrote:
> David Crossley wrote:
> >Ross Gardler wrote:
[ snip ]
> >>I just verified I was at the latest release of Forrest, and did a clean
> >>build (somehow I always forget to do that). But no change.
I double-checked again :-) that i have no un-committed files.
Perhaps you should try a complete fresh checkout.
However before you do that ...
Recently i upgraded the entity resolver jar to a new
pre-release. Today i reverted that, so lets see if that
helps you.
> >So does the entity resolver also fail for you with all
> >the normal processing, e.g. in forrest/site-author
> >doing 'forrest site'?
>
> site-author does not have any files that contain a DTD reference used by
> a plugin, so it works with SVN head.
>
> However, if I add:
>
> <!DOCTYPE status PUBLIC "-//APACHE//DTD Status V1.3//EN" "status-v13.dtd">
>
> to status.xml in site-author it fails.
>
> If I use:
>
> <!DOCTYPE status PUBLIC "-//APACHE//DTD Status V1.3//EN"
> "http://forrest.apache.org/dtd/status-v13.dtd">
>
> (note full URL of DTD) then it works (presumambly the resolver goes to
> the website, I've not checked this traffic.
Yep, those two tests prove that it is failing for you.
And if this is failing then it means that *all* DTDs
are being retrieved from the website. Wow, using Forrest
must be very slow for you.
I made the change that you suggested above and i have no
problems. Doing 'sudo ngrep dtd' also proves that there
is no network traffic.
When you do the command-line 'forrest' are there any
strange messages at the "validate-xdocs" target?
> >Please switch the verbosity level to 10 in
> >WEB-INF/xconf/forrest-core.xconf and send me
> >the output.
>
> The relevant parts are:
>
> At Startup:
>
>
> Parse catalog:
> file:/D:/openSource/forrest/main/webapp/resources/schema/catalog.
> xcat
> Loading catalog:
> file:/D:/openSource/forrest/main/webapp/resources/schema/catalo
> g.xcat
> Default BASE:
> file://D:/D:/openSource/forrest/main/webapp/resources/schema/catal
> og.xcat
> Parse text/plain catalog on input stream
> No CatalogReader for MIME type: text/plain
Hmmm, i have never seen those two lines.
That sounds like the primary forrest catalog is not
being loaded.
These are the messages that i get at startup:
------
Parse catalog: file:/svn/asf/forrest/main/webapp/./resources/schema/catalog.xcat
Loading catalog: file:/svn/asf/forrest/main/webapp/./resources/schema/catalog.xcat
Default BASE: file:/svn/asf/forrest/main/webapp/./resources/schema/catalog.xcat
override: yes
OVERRIDE: yes
nextCatalog: catalog.forrest.xcat
CATALOG: file:/svn/asf/forrest/main/webapp/resources/schema/catalog.forrest.xcat
nextCatalog: w3c-dtd/catalog.xcat
CATALOG: file:/svn/asf/forrest/main/webapp/resources/schema/w3c-dtd/catalog.xcat
nextCatalog: docbook/catalog.xcat
CATALOG: file:/svn/asf/forrest/main/webapp/resources/schema/docbook/catalog.xcat
nextCatalog: sdocbook/catalog.xcat
CATALOG: file:/svn/asf/forrest/main/webapp/resources/schema/sdocbook/catalog.xcat
nextCatalog: open-office/catalog.xcat
CATALOG: file:/svn/asf/forrest/main/webapp/resources/schema/open-office/catalog.xcat
------
I snipped the rest of Ross' output. The messages prove
that it is failing because there are no messages like
Resolved public: ...
which would show the entity resolver doing its job.
--David
> >Does this problem occur for anyone else?
>
> Anyone?
>
> To attempt to reproduce add the following doctype definitions to
> site-author/status.xml
>
> <!DOCTYPE status PUBLIC "-//APACHE//DTD Status V1.3//EN" "status-v13.dtd">
>
> Ross
Re: possible entity resolver failure (Was: svn commit: r164099)
Posted by Ross Gardler <rg...@apache.org>.
David Crossley wrote:
> Ross Gardler wrote:
>
>>David Crossley wrote:
>>
>>>Ross Gardler wrote:
>>>
>>>
>>>>David Crossley wrote:
>>>>
>>>>
>>>>>I don't understand what you mean Ross. It already works for me,
>>>>>the catalog entity resolver finds the local "status DTD".
>>>>>
>>>>>That can be proved that by changing the publicIdentifier
>>>>>in status.xml to be deliberately broken, then it fails
>>>>>as it should,
>>>>>e.g. ... PUBLIC "-//APACHE//DTD Status Foo-Bust V1.3//EN"
>>>>
>>>>Well it isn't working for me. Forrest appears to not be resolving the
>>>>catalogs since it is looking in the local directory for the DTD.
>>>>
>>>>This happens for the projectInfo, OpenOffice.org and simplified-docbook
>>>>plugins.
>>>>
>>>>Any ideas?
>>>
>>>How are you invoking forrest?
>>>If it is in the plugins directory using
>>>'forrest/tools/ant/bin/ant test'
>>>then did you remember the recent discussion
>>>about the system Ant libs missing resolver.jar
>>>http://forrest.apache.org/0.7/docs/howto/howto-buildPlugin.html#ant
>>
>>Yep, I have xml-commons-resolver,jar in my ant lib directory.
>>
>>It occurs however I run forrest:
>>
>>ant test
>>forrest site
>>forrest run
>>
>>I just verified I was at the latest release of Forrest, and did a clean
>>build (somehow I always forget to do that). But no change.
>
>
> So does the entity resolver also fail for you with all
> the normal processing, e.g. in forrest/site-author
> doing 'forrest site'?
site-author does not have any files that contain a DTD reference used by
a plugin, so it works with SVN head.
However, if I add:
<!DOCTYPE status PUBLIC "-//APACHE//DTD Status V1.3//EN" "status-v13.dtd">
to status.xml in site-author it fails.
If I use:
<!DOCTYPE status PUBLIC "-//APACHE//DTD Status V1.3//EN"
"http://forrest.apache.org/dtd/status-v13.dtd">
(note full URL of DTD) then it works (presumambly the resolver goes to
the website, I've not checked this traffic.
> Please switch the verbosity level to 10 in
> WEB-INF/xconf/forrest-core.xconf and send me
> the output.
The relevant parts are:
At Startup:
Parse catalog:
file:/D:/openSource/forrest/main/webapp/resources/schema/catalog.
xcat
Loading catalog:
file:/D:/openSource/forrest/main/webapp/resources/schema/catalo
g.xcat
Default BASE:
file://D:/D:/openSource/forrest/main/webapp/resources/schema/catal
og.xcat
Parse text/plain catalog on input stream
No CatalogReader for MIME type: text/plain
Requesting with the failing doctype above (not http://)
resolveSystem(file:/D:/openSource/forrest/site-author/status-v13.dtd)
resolvePublic(-//APACHE//DTD Status
V1.3//EN,file:/D:/openSource/forrest/site-au
thor/status-v13.dtd)
Requesting with the succeeding doctype (with http;//):
resolveSystem(http://forrest.apache.org/dtd/status-v13.dtd)
resolvePublic(-//APACHE//DTD Status
V1.3//EN,http://forrest.apache.org/dtd/statu
s-v13.dtd)
resolveSystem(http://forrest.apache.org/dtd/document-v13.mod)
resolvePublic(-//APACHE//ENTITIES Documentation
V1.3//EN,http://forrest.apache.o
rg/dtd/document-v13.mod)
resolveSystem(http://forrest.apache.org/dtd/common-charents-v10.mod)
resolvePublic(-//APACHE//ENTITIES Common Character Entity Sets
V1.0//EN,http://f
orrest.apache.org/dtd/common-charents-v10.mod)
resolveSystem(http://forrest.apache.org/entity/ISOlat1.pen)
resolvePublic(ISO 8879:1986//ENTITIES Added Latin
1//EN//XML,http://forrest.apac
he.org/entity/ISOlat1.pen)
resolveSystem(http://forrest.apache.org/entity/ISOpub.pen)
resolvePublic(ISO 8879:1986//ENTITIES
Publishing//EN//XML,http://forrest.apache.
org/entity/ISOpub.pen)
resolveSystem(http://forrest.apache.org/entity/ISOtech.pen)
resolvePublic(ISO 8879:1986//ENTITIES General
Technical//EN//XML,http://forrest.
apache.org/entity/ISOtech.pen)
resolveSystem(http://forrest.apache.org/entity/ISOnum.pen)
resolvePublic(ISO 8879:1986//ENTITIES Numeric and Special
Graphic//EN//XML,http:
//forrest.apache.org/entity/ISOnum.pen)
resolveSystem(http://forrest.apache.org/entity/ISOdia.pen)
resolvePublic(ISO 8879:1986//ENTITIES Diacritical
Marks//EN//XML,http://forrest.
apache.org/entity/ISOdia.pen)
resolveSystem(http://forrest.apache.org/dtd/common-elems-v10.mod)
resolvePublic(-//APACHE//ENTITIES Common Elements
V1.0//EN,http://forrest.apache
.org/dtd/common-elems-v10.mod)
resolveSystem(http://forrest.apache.org/dtd/changes-v11.mod)
resolvePublic(-//APACHE//ENTITIES Changes
V1.1//EN,http://forrest.apache.org/dtd
/changes-v11.mod)
resolveSystem(http://forrest.apache.org/dtd/todo-v11.mod)
resolvePublic(-//APACHE//ENTITIES Todo
V1.1//EN,http://forrest.apache.org/dtd/to
do-v11.mod)
resolveSystem(http://forrest.apache.org/dtd/status-v13.mod)
resolvePublic(-//APACHE//ENTITIES Status
V1.3//EN,http://forrest.apache.org/dtd/
status-v13.mod)
When requesting a file such as index.html (after a restart to ensure no
cached DTD files) I get:
resolveSystem(http://forrest.apache.org/dtd/skinconfig-v06-3.dtd)
resolvePublic(-//APACHE//DTD Skin Configuration
V0.6-3//EN,http://forrest.apache
.org/dtd/skinconfig-v06-3.dtd)
resolveSystem(http://forrest.apache.org/dtd/tab-cocoon-v11.dtd)
resolvePublic(-//APACHE//DTD Cocoon Documentation Tab
V1.1//EN,http://forrest.ap
ache.org/dtd/tab-cocoon-v11.dtd)
Lazy mode: false
resolveSystem(http://forrest.apache.org/dtd/document-v12.dtd)
resolvePublic(-//APACHE//DTD Documentation
V1.2//EN,http://forrest.apache.org/dt
d/document-v12.dtd)
resolveSystem(http://forrest.apache.org/dtd/common-charents-v10.mod)
resolvePublic(-//APACHE//ENTITIES Common Character Entity Sets
V1.0//EN,http://f
orrest.apache.org/dtd/common-charents-v10.mod)
resolveSystem(http://forrest.apache.org/entity/ISOlat1.pen)
resolvePublic(ISO 8879:1986//ENTITIES Added Latin
1//EN//XML,http://forrest.apac
he.org/entity/ISOlat1.pen)
resolveSystem(http://forrest.apache.org/entity/ISOpub.pen)
resolvePublic(ISO 8879:1986//ENTITIES
Publishing//EN//XML,http://forrest.apache.
org/entity/ISOpub.pen)
resolveSystem(http://forrest.apache.org/entity/ISOtech.pen)
resolvePublic(ISO 8879:1986//ENTITIES General
Technical//EN//XML,http://forrest.
apache.org/entity/ISOtech.pen)
resolveSystem(http://forrest.apache.org/entity/ISOnum.pen)
resolvePublic(ISO 8879:1986//ENTITIES Numeric and Special
Graphic//EN//XML,http:
//forrest.apache.org/entity/ISOnum.pen)
resolveSystem(http://forrest.apache.org/entity/ISOdia.pen)
resolvePublic(ISO 8879:1986//ENTITIES Diacritical
Marks//EN//XML,http://forrest.
apache.org/entity/ISOdia.pen)
resolveSystem(http://forrest.apache.org/dtd/document-v12.mod)
resolvePublic(-//APACHE//ENTITIES Documentation
V1.2//EN,http://forrest.apache.o
rg/dtd/document-v12.mod)
> Does this problem occur for anyone else?
Anyone?
To attempt to reproduce add the following doctype definitions to
site-author/status.xml
<!DOCTYPE status PUBLIC "-//APACHE//DTD Status V1.3//EN" "status-v13.dtd">
Ross
possible entity resolver failure (Was: svn commit: r164099)
Posted by David Crossley <cr...@apache.org>.
Ross Gardler wrote:
> David Crossley wrote:
> >Ross Gardler wrote:
> >
> >>David Crossley wrote:
> >>
> >>>I don't understand what you mean Ross. It already works for me,
> >>>the catalog entity resolver finds the local "status DTD".
> >>>
> >>>That can be proved that by changing the publicIdentifier
> >>>in status.xml to be deliberately broken, then it fails
> >>>as it should,
> >>>e.g. ... PUBLIC "-//APACHE//DTD Status Foo-Bust V1.3//EN"
> >>
> >>Well it isn't working for me. Forrest appears to not be resolving the
> >>catalogs since it is looking in the local directory for the DTD.
> >>
> >>This happens for the projectInfo, OpenOffice.org and simplified-docbook
> >>plugins.
> >>
> >>Any ideas?
> >
> >How are you invoking forrest?
> >If it is in the plugins directory using
> >'forrest/tools/ant/bin/ant test'
> >then did you remember the recent discussion
> >about the system Ant libs missing resolver.jar
> >http://forrest.apache.org/0.7/docs/howto/howto-buildPlugin.html#ant
>
> Yep, I have xml-commons-resolver,jar in my ant lib directory.
>
> It occurs however I run forrest:
>
> ant test
> forrest site
> forrest run
>
> I just verified I was at the latest release of Forrest, and did a clean
> build (somehow I always forget to do that). But no change.
So does the entity resolver also fail for you with all
the normal processing, e.g. in forrest/site-author
doing 'forrest site'?
Please switch the verbosity level to 10 in
WEB-INF/xconf/forrest-core.xconf and send me
the output.
Does this problem occur for anyone else?
--David
Re: svn commit: r164099 - /forrest/trunk/plugins/org.apache.forrest.plugin.input.projectInfo/status.xml
Posted by Ross Gardler <rg...@apache.org>.
David Crossley wrote:
> Ross Gardler wrote:
>
>>David Crossley wrote:
>>
>>>I don't understand what you mean Ross. It already works for me,
>>>the catalog entity resolver finds the local "status DTD".
>>>
>>>That can be proved that by changing the publicIdentifier
>>>in status.xml to be deliberately broken, then it fails
>>>as it should,
>>>e.g. ... PUBLIC "-//APACHE//DTD Status Foo-Bust V1.3//EN"
>>
>>Well it isn't working for me. Forrest appears to not be resolving the
>>catalogs since it is looking in the local directory for the DTD.
>>
>>This happens for the projectInfo, OpenOffice.org and simplified-docbook
>>plugins.
>>
>>Any ideas?
>
>
> How are you invoking forrest?
> If it is in the plugins directory using
> 'forrest/tools/ant/bin/ant test'
> then did you remember the recent discussion
> about the system Ant libs missing resolver.jar
> http://forrest.apache.org/0.7/docs/howto/howto-buildPlugin.html#ant
Yep, I have xml-commons-resolver,jar in my ant lib directory.
It occurs however I run forrest:
ant test
forrest site
forrest run
I just verified I was at the latest release of Forrest, and did a clean
build (somehow I always forget to do that). But no change.
Ross
Re: svn commit: r164099 - /forrest/trunk/plugins/org.apache.forrest.plugin.input.projectInfo/status.xml
Posted by David Crossley <cr...@apache.org>.
Ross Gardler wrote:
> David Crossley wrote:
> >I don't understand what you mean Ross. It already works for me,
> >the catalog entity resolver finds the local "status DTD".
> >
> >That can be proved that by changing the publicIdentifier
> >in status.xml to be deliberately broken, then it fails
> >as it should,
> >e.g. ... PUBLIC "-//APACHE//DTD Status Foo-Bust V1.3//EN"
>
> Well it isn't working for me. Forrest appears to not be resolving the
> catalogs since it is looking in the local directory for the DTD.
>
> This happens for the projectInfo, OpenOffice.org and simplified-docbook
> plugins.
>
> Any ideas?
How are you invoking forrest?
If it is in the plugins directory using
'forrest/tools/ant/bin/ant test'
then did you remember the recent discussion
about the system Ant libs missing resolver.jar
http://forrest.apache.org/0.7/docs/howto/howto-buildPlugin.html#ant
--David
Re: svn commit: r164099 - /forrest/trunk/plugins/org.apache.forrest.plugin.input.projectInfo/status.xml
Posted by Ross Gardler <rg...@apache.org>.
David Crossley wrote:
> I don't understand what you mean Ross. It already works for me,
> the catalog entity resolver finds the local "status DTD".
>
> That can be proved that by changing the publicIdentifier
> in status.xml to be deliberately broken, then it fails
> as it should,
> e.g. ... PUBLIC "-//APACHE//DTD Status Foo-Bust V1.3//EN"
Well it isn't working for me. Forrest appears to not be resolving the
catalogs since it is looking in the local directory for the DTD.
This happens for the projectInfo, OpenOffice.org and simplified-docbook
plugins.
Any ideas?
Ross
Re: svn commit: r164099 - /forrest/trunk/plugins/org.apache.forrest.plugin.input.projectInfo/status.xml
Posted by David Crossley <cr...@apache.org>.
I don't understand what you mean Ross. It already works for me,
the catalog entity resolver finds the local "status DTD".
That can be proved that by changing the publicIdentifier
in status.xml to be deliberately broken, then it fails
as it should,
e.g. ... PUBLIC "-//APACHE//DTD Status Foo-Bust V1.3//EN"
--David
> Author: rgardler
> Date: Thu Apr 21 11:56:27 2005
> New Revision: 164099
>
> URL: http://svn.apache.org/viewcvs?rev=164099&view=rev
> Log:
> [WORKAROUND] use URL for DTD as plugin is fails to find it using the catalogs
>
> Modified:
> forrest/trunk/plugins/org.apache.forrest.plugin.input.projectInfo/status.xml
>
> Modified: forrest/trunk/plugins/org.apache.forrest.plugin.input.projectInfo/status.xml
> URL: http://svn.apache.org/viewcvs/forrest/trunk/plugins/org.apache.forrest.plugin.input.projectInfo/status.xml?rev=164099&r1=164098&r2=164099&view=diff
> ==============================================================================
> --- forrest/trunk/plugins/org.apache.forrest.plugin.input.projectInfo/status.xml (original)
> +++ forrest/trunk/plugins/org.apache.forrest.plugin.input.projectInfo/status.xml Thu Apr 21 11:56:27 2005
> @@ -15,7 +15,7 @@
> See the License for the specific language governing permissions and
> limitations under the License.
> -->
> -<!DOCTYPE status PUBLIC "-//APACHE//DTD Status V1.3//EN" "status-v13.dtd">
> +<!DOCTYPE status PUBLIC "-//APACHE//DTD Status V1.3//EN" "http://forrest.apache.org/dtd/status-v13.dtd">
> <status>
>
> <developers>
>