Nabble - Apache XML - Commons - Dev

DO NOT REPLY [Bug 48434] New: Problem in sending greece charcters over axis

2009-12-23T03:21:41Z

https://issues.apache.org/bugzilla/show_bug.cgi?id=48434

Summary: Problem in sending greece charcters over axis
Product: XmlCommons
Version: 1.x
Platform: PC
OS/Version: Windows Server 2003
Status: NEW
Severity: major
Priority: P2
Component: SAX
AssignedTo: commons-dev@...
ReportedBy: aseem.bathla1@...

Hi All,

I need one help from you. I have published a Web Service. There is one method
in web service which accepts a String as input parameter.
The value of this String should be an xml Template which is

<?xml version="1.0" encoding="ISO-8859-1"?>
<emailDetails xmlns="http://xyz.net/abc/namespace"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://xyz.net/abc/namespace
C:\java\aaa\xml\emailXMLSchema.xsd">
<subject>Subj in Greece: Νέες ευκαιρίες απασχόλησης</subject>
<type>Subj in Greece: Νέες ευκαιρίες απασχόλησης</type>
<url><![CDATAhttp://localhost:8080/AppName/activate_new_account.jsp?key=KEY_HOLE]></url>
<bodyText>
<![CDATA[<html><body><p>
Νέες ευκαιρίες απασχόλησης: Ιατρικοί Επισκέπτες Αθήνα/Θεσσαλονίκη/Ιωάννινα
/Ηράκλειο Κρήτης/Καβάλα/Τρίκαλα/Σέρρες
</body></html>]]>
</bodyText>
<from>aseem.bathla1@...</from>
</emailDetails>

My webservice accepts this content in the form of String Object. It will parse
this template(String object) using SAX parser and finds the following attribute
Subject,Body,From,Recipient and constructs and sends out the mail to the
recipient which is working fine with English language. I have some Greece
clients also. When i edited the body part in Greek language. Instead of sending
those Greek characters some question marks are coming to that mail.
I extracted the code out which parses that XML Template and sends out the mail.
I created one java project using that code. Parser parsed that template and
sent the mail successfully with the Greek characters. I suspect that Axis or
Soap engine is not supporting Greece Characters.But when i am using that code
in webservice it is not working. So i suspect that axis does not support Greece
characters.
I tried with encoding="ISO-8859-7" and UTF-8 both but it din't work.

Could any one help me in solving this problem?

Thanks,
Aseem Bathla

--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

[ANNOUNCEMENT]: XML Commons External 1.2.06 now available

2009-12-16T22:57:27Z

Hi everyone,

The XML Commons team is pleased to announce that version 1.2.06 of XML Commons External is now available. This is a maintenance release of the JAXP 1.2 APIs which were included in Xerces-J 2.6.2 and earlier. Specifically, the changes introduced in this release are:

* Fixed a bug in StreamResult where it was not escaping non-ASCII characters in its conversion of a java.io.File object to a system identifier.

* Modified the FactoryFinder and SecuritySupport classes to prevent them from being extended or instantiated.

* Eliminated the creation of temporary Boolean objects in the SecuritySupport classes.

* Eliminated the creation of short lived StringBuffer and String objects in each of the FactoryFinder classes. The debug print method calls were creating instances of StringBuffer and String which were never read.

* Updated each of the JAXP factory classes so that they treat an empty string value for their system property as if it had not been set. Previously the factories would make a futile attempt to create an instance of a class named "" and then fail.

* Fixed the Implementation-Vendor and Implementation-URL entries in the jar manifest.

* Fixed miscellaneous typographical errors in the Javadocs.

The source and binary distributions are available for download here: http://xerces.apache.org/mirrors.cgi

For more information please visit: http://xml.apache.org/commons/

Michael Glavassevich XML Parser Development IBM Toronto Lab E-mail: mrglavas@...
E-mail: mrglavas@...

[ANNOUNCEMENT]: XML Commons External 1.3.05 now available

2009-12-16T22:50:14Z

Hi everyone,

The XML Commons team is pleased to announce that version 1.3.05 of XML Commons External is now available. This is a maintenance release of the JAXP 1.3 APIs which were included in Xerces-J 2.7.0 to Xerces-J 2.9.1.Specifically, the changes introduced in this release are:

* Fixed bugs in SchemaFactory and XPathFactory which caused them to always use the system ClassLoader when searching for META-INF/services files instead of the ClassLoader that would be used to load the concrete factory class.

* Fixed the FactoryFinders so that they no longer catch and ignore ThreadDeath and serious VM errors such as an OutOfMemoryError or a StackOverflowError.

* Fixed the default implementation of DatatypeFactory.createDurationDayTime(long) so that it behaves according to the JAXP specification. Previously it was just delegating to DatatypeFactory.newDuration(long) which has different behaviour than the createDurationDayTime method.

* Corrected the default implementations of DatatypeFactory.newDurationYearMonth() and DatatypeFactory.newDurationDayTime() so that they behave according to the JAXP specification. These methods must reject lexical values which are not valid instances of xs:yearMonthDuration and xs:dayTimeDuration. They were not doing so before.

* Fixed bugs which could cause NullPointerExceptions to be thrown from the default implementations of Duration.getYears(), Duration.getMonths(), etc...

* Fixed bugs in the DatatypeFactory.newDurationDayTime() and DatatypeFactory.newDurationYearMonth() methods where BigIntegers were being created for DatatypeConstants.FIELD_UNDEFINED values instead of assigning the value to null in the Duration.

* Updated each of the JAXP factory classes so that they treat an empty string value for their system property as if it had not been set. Previously the factories would make a futile attempt to create an instance of a class named "" and then fail.

* Implemented minor performance improvements in XMLGregorianCalendar.equals() and Duration.equals(). If the given object is "this" object return true immediately.

* Eliminated an unnecessary conversion to String in Duration.multiply(int).

* Updated the File to URI conversion code in StreamResult so that it is consistent with StreamSource.

* Fixed miscellaneous typographical errors in the Javadocs.

The source and binary distributions are available for download here: http://xerces.apache.org/mirrors.cgi

For more information please visit: http://xml.apache.org/commons/

Michael Glavassevich XML Parser Development IBM Toronto Lab E-mail: mrglavas@...
E-mail: mrglavas@...

Re: Unable to build xml-commons website with Forrest 0.7

2009-12-16T22:35:36Z

David Crossley <crossley@...> wrote on 12/17/2009 01:26:51 AM: > Michael Glavassevich wrote: > > Tim Williams wrote: > > > > > > Without all the initial output from the build it's tough to say, but I > > > wonder if you've run into a plugin version problem[1]. Would it be > > > much trouble to upgrade to 0.8? I have no clue whether this would > > > work or not with a 0.7 instance, but if you can't just upgrade, you > > > might try adding a 0.1 extension to the pdf plugin - though, honestly, > > > I haven't seen that error before in an instance like that. > > > > 0.8 (which I tried first) didn't work for me either, so gave 0.7 a spin > > because it was listed in the build instructions for the site. David's > > suggestion to turn off PDF generation did the trick. > > > > > --tim > > > > > > [1] - http://forrest.apache.org/docs_0_80/faq.html#older-plugins > > Yes, i wondered if this might be the issue. > > The PDF plugin was upgraded recently and re-deployed. > However it was not deployed properly, by incrementing its > version numbers. So the currently deployed plugin cannot > be used with 0.7 or 0.8 versions of Forrest.
Ah. I was about to ask how this could have worked before. That explains it.
> I made the following change to forrest.properties to use an > old version of the PDF plugin, and committed it to xml-commons today. > It now works for me with Forrest-0.7
Thanks for that. I'm republishing the site right now with the PDFs.
> -------------- > - > project.required.plugins=org.apache.forrest.plugin.output.pdf,org.apache.forrest.plugin.input.projectInfo-0. > 1 > +project.required.plugins=org.apache.forrest.plugin.output.pdf-0. > 1,org.apache.forrest.plugin.input.projectInfo-0.1 > -------------- > > We will take that up on our dev list. > > Sorry for the inconvenience. > > -David

Michael Glavassevich XML Parser Development IBM Toronto Lab E-mail: mrglavas@...
E-mail: mrglavas@...

DO NOT REPLY [Bug 48402] [patch] miscellaneous minor cleanups

2009-12-16T22:29:15Z

https://issues.apache.org/bugzilla/show_bug.cgi?id=48402

--- Comment #1 from Dave Brosius <dbrosius@...> 2009-12-16 22:29:14 UTC ---
Created an attachment (id=24719)
--> (https://issues.apache.org/bugzilla/attachment.cgi?id=24719)
miscellaneous fixes

--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

DO NOT REPLY [Bug 48402] New: [patch] miscellaneous minor cleanups

2009-12-16T22:28:30Z

https://issues.apache.org/bugzilla/show_bug.cgi?id=48402

Summary: [patch] miscellaneous minor cleanups
Product: XmlCommons
Version: 1.x
Platform: PC
OS/Version: Linux
Status: NEW
Severity: trivial
Priority: P2
Component: Resolver
AssignedTo: commons-dev@...
ReportedBy: dbrosius@...

Fix various issues including

switch to use 'modern--1.2' collection apis
remove unused assignments
fix javadoc
fix bloated assignment scope
remove duplication
make sure files are closed
npe guards
remove unnecessary fields

--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

Re: Unable to build xml-commons website with Forrest 0.7

2009-12-16T22:26:37Z

Michael Glavassevich wrote:

> Tim Williams wrote:
> >
> > Without all the initial output from the build it's tough to say, but I
> > wonder if you've run into a plugin version problem[1]. Would it be
> > much trouble to upgrade to 0.8? I have no clue whether this would
> > work or not with a 0.7 instance, but if you can't just upgrade, you
> > might try adding a 0.1 extension to the pdf plugin - though, honestly,
> > I haven't seen that error before in an instance like that.
>
> 0.8 (which I tried first) didn't work for me either, so gave 0.7 a spin
> because it was listed in the build instructions for the site. David's
> suggestion to turn off PDF generation did the trick.
>
> > --tim
> >
> > [1] - http://forrest.apache.org/docs_0_80/faq.html#older-plugins

Yes, i wondered if this might be the issue.

The PDF plugin was upgraded recently and re-deployed.
However it was not deployed properly, by incrementing its
version numbers. So the currently deployed plugin cannot
be used with 0.7 or 0.8 versions of Forrest.

I made the following change to forrest.properties to use an
old version of the PDF plugin, and committed it to xml-commons today.
It now works for me with Forrest-0.7

--------------
-project.required.plugins=org.apache.forrest.plugin.output.pdf,org.apache.forrest.plugin.input.projectInfo-0.1
+project.required.plugins=org.apache.forrest.plugin.output.pdf-0.1,org.apache.forrest.plugin.input.projectInfo-0.1
--------------

We will take that up on our dev list.

Sorry for the inconvenience.

-David

Re: Unable to build xml-commons website with Forrest 0.7

2009-12-16T22:19:30Z

Michael Glavassevich wrote:

> David Crossley wrote:
> >
> > One workaround to get the release published would be to disable
> > the "PDF" production:
> > In src/documentation/skinconf.xml disable-pdf-link = true
> > In forrest.properties project.required.plugins remove pdf plugin
>
> Thanks, that worked well enough to get the pages I wanted generated, but it
> still didn't complete cleanly:
>
> "Logging Error: Writing event to closed stream.
> Total time: 0 minutes 20 seconds, Site size: 230,302 Site pages: 38
>
> BUILD FAILED
> D:\apache-forrest-0.7\main\targets\site.xml:41: Java returned: 1"
>
> I'm not going to worry about that though.

Yes it is a strange message with forrest-0.7 that is ignorable.

> I'm just trying to build an existing site (that I didn't develop aside from
> adding a little bit of content). I'm not sure what requirements it has, but
> I tried 0.8 first and it also didn't work. I vaguely remember the last time
> around having to pick up a dev version of 0.7 and applying at least one
> patch to it from SVN. Given that I couldn't get it to build cleanly with
> 0.7 or 0.8 I have suspicion that the XML Commons site is locked into some
> unreleased in-development version of Forrest (0.7?) and won't build
> normally without that. At least I got the pages I needed after turning PDF
> generation off.

That is not what i recall.

At the time, 0.7 was the current release of Forrest.
The XML Commons project has not updated to Forrest-0.8 yet.
So the Commons documentation still says that 0.7 is the
agreed version in use.

The reason is as Tim described in another message today.
See my later reply there.

-David

Re: Unable to build xml-commons website with Forrest 0.7

2009-12-16T19:26:31Z

Tim,

Tim Williams <williamstw@...> wrote on 12/16/2009 07:18:02 PM: > Without all the initial output from the build it's tough to say, but I > wonder if you've run into a plugin version problem[1]. Would it be > much trouble to upgrade to 0.8? I have no clue whether this would > work or not with a 0.7 instance, but if you can't just upgrade, you > might try adding a 0.1 extension to the pdf plugin - though, honestly, > I haven't seen that error before in an instance like that.
0.8 (which I tried first) didn't work for me either, so gave 0.7 a spin because it was listed in the build instructions for the site. David's suggestion to turn off PDF generation did the trick.
> --tim > > [1] - http://forrest.apache.org/docs_0_80/faq.html#older-plugins

Thanks.

Michael Glavassevich XML Parser Development IBM Toronto Lab E-mail: mrglavas@...
E-mail: mrglavas@...

Re: Unable to build xml-commons website with Forrest 0.7

2009-12-16T19:20:20Z

David,

David Crossley <crossley@...> wrote: > Michael Glavassevich wrote: > > > > It's been a long time since I've tried building the XML Commons website and > > I'm not sure how to get past this. I tried to build the site with a fresh > > install of Forrest 0.7 (recommended in the build instructions on the XML > > Commons website [1]) but had no luck. Hoping someone who uses Forrest more > > often would have an idea what's going on here. > > I cannot help with those errors. > > One workaround to get the release published would be to disable > the "PDF" production: > In src/documentation/skinconf.xml disable-pdf-link = true > In forrest.properties project.required.plugins remove pdf plugin > > -David

Thanks, that worked well enough to get the pages I wanted generated, but it still didn't complete cleanly:

"Logging Error: Writing event to closed stream.
Total time: 0 minutes 20 seconds, Site size: 230,302 Site pages: 38

BUILD FAILED
D:\apache-forrest-0.7\main\targets\site.xml:41: Java returned: 1"

I'm not going to worry about that though.

------------------------

Thomas,

Thomas Witteriede <thomas@...> wrote:

> Hi,
> do you have any special requirements so that you are using Forrest 0.7?
> The current stable release (to my knowledge) is 0.8, if it is not 0.9
> already. Have a go with 0.8 and if you are using Windows, it might be
> worth a try to use an older Java version (1.5_xx) instead of a current
> one (works for me).
> The web page you quoted seems ancient, go to
> http://forrest.apache.org/docs_0_80/your-project.html#installing for a
> more current doc on installing and using Forrest.
>
> Best regards
> Thomas

I'm just trying to build an existing site (that I didn't develop aside from adding a little bit of content). I'm not sure what requirements it has, but I tried 0.8 first and it also didn't work. I vaguely remember the last time around having to pick up a dev version of 0.7 and applying at least one patch to it from SVN. Given that I couldn't get it to build cleanly with 0.7 or 0.8 I have suspicion that the XML Commons site is locked into some unreleased in-development version of Forrest (0.7?) and won't build normally without that. At least I got the pages I needed after turning PDF generation off.

Thanks.
Michael Glavassevich XML Parser Development IBM Toronto Lab E-mail: mrglavas@...
E-mail: mrglavas@...

Re: Unable to build xml-commons website with Forrest 0.7

2009-12-16T14:27:00Z

Michael Glavassevich wrote:
>
> It's been a long time since I've tried building the XML Commons website and
> I'm not sure how to get past this. I tried to build the site with a fresh
> install of Forrest 0.7 (recommended in the build instructions on the XML
> Commons website [1]) but had no luck. Hoping someone who uses Forrest more
> often would have an idea what's going on here.

I cannot help with those errors.

One workaround to get the release published would be to disable
the "PDF" production:
In src/documentation/skinconf.xml disable-pdf-link = true
In forrest.properties project.required.plugins remove pdf plugin

-David

[ANNOUNCEMENT]: XML Commons External 1.4.01 now available

2009-12-16T14:15:26Z

Hi everyone, The XML Commons team is pleased to announce that version 1.4.01 of XML Commons External is now available. This release updates the XML APIs to JAXP 1.4 and also introduces the StAX 1.0 and theElement Traversal APIs. XML Commons External 1.4.01 will be included in the upcoming release of Xerces-J 2.10.0.

Specifically, the changes introduced in this release are:

* Added classes and method signatures introduced by JAXP 1.4.

* Added the StAX 1.0 API (JSR 173). Sources based off of the distribution from Apache Geronimo.

* Added the Java Language Binding for the Element Traversal API (org.w3c.dom.ElementTraversal).

* Added default implementations to SchemaFactory for the XML Schema 1.0 and 1.1 language identifiers.

* Fixed bugs in SchemaFactory and XPathFactory which caused them to always use the system ClassLoader when searching for META-INF/services files instead of the ClassLoader that would be used to load the concrete factory class.

* Updated each of the JAXP factory classes so that they treat an empty string value for their system property as if it had not been set. Previously the factories would make a futile attempt to create an instance of a class named "" and then fail.

* Fixed the FactoryFinders so that they no longer catch and ignore ThreadDeath and serious VM errors such as an OutOfMemoryError or a StackOverflowError.

* Fixed the default implementation of DatatypeFactory.createDurationDayTime(long) so that it behaves according to the JAXP specification. Previously it was just delegating to DatatypeFactory.newDuration(long) which has different behaviour than the createDurationDayTime method.

* Corrected the default implementations of DatatypeFactory.newDurationYearMonth() and DatatypeFactory.newDurationDayTime() so that they behave according to the JAXP specification. These methods must reject lexical values which are not valid instances of xs:yearMonthDuration and xs:dayTimeDuration. They were not doing so before.

* Fixed bugs which could cause NullPointerExceptions to be thrown from the default implementations of Duration.getYears(), Duration.getMonths(), etc...

* Fixed bugs in the DatatypeFactory.newDurationDayTime() and DatatypeFactory.newDurationYearMonth() methods where BigIntegers were being created for DatatypeConstants.FIELD_UNDEFINED values instead of assigning the value to null in the Duration.

* Implemented minor performance improvements in XMLGregorianCalendar.equals() and Duration.equals(). If the given object is "this" object return true immediately.

* Eliminated an unnecessary conversion to String in Duration.multiply(int).

* Updated the File to URI conversion code in StreamResult so that it is consistent with StreamSource.

* Fixed miscellaneous typographical errors in the Javadocs.

The source and binary distributions are available for download here: http://xerces.apache.org/mirrors.cgi

For more information please visit: http://xml.apache.org/commons/

Michael Glavassevich XML Parser Development IBM Toronto Lab E-mail: mrglavas@...
E-mail: mrglavas@...

Unable to build xml-commons website with Forrest 0.7

2009-12-16T09:11:53Z

Hi all,

It's been a long time since I've tried building the XML Commons website and I'm not sure how to get past this. I tried to build the site with a fresh install of Forrest 0.7 (recommended in the build instructions on the XML Commons website [1]) but had no luck. Hoping someone who uses Forrest more often would have an idea what's going on here.

Here's the log from the build failure:

Static site will be generated at:
D:\eclipse3.4.1\workspace\xml-commons-trunk\build\site

Note that there are various reasons for "build failed" messages.
* Cocoon will report the status of each document:
- in column 1: *=okay X=brokenLink ^=pageSkipped (see FAQ).
* Even if only one link is broken, you will still get "failed".
* Your site would still be generated, but some pages would be broken.
* Please check the file:
D:\eclipse3.4.1\workspace\xml-commons-trunk\build\tmp\brokenlinks.xml
for any broken links in the generated site.
------------------------------------------------------------------------
cocoon 2.2.0-dev
Copyright (c) 1999-2005 Apache Software Foundation. All rights reserved.
------------------------------------------------------------------------
Lazy mode: true
Cannot find CatalogManager.properties
Lazy mode: true
Lazy mode: true
Lazy mode: true
Lazy mode: true
Lazy mode: true
org.apache.avalon.framework.configuration.ConfigurationException: Error while cr
eating node 'select' at file:/D:/apache-forrest-0.7/build/plugins/org.apache.for
rest.plugin.output.pdf/output.xmap:28:35
at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNo
deBuilder.buildChildNodesList(AbstractParentProcessingNodeBuilder.java:128)
* [1/0] [0/0] 0.375s 0b linkmap.html
at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNo
deBuilder.buildChildNodes(AbstractParentProcessingNodeBuilder.java:136)
at org.apache.cocoon.components.treeprocessor.sitemap.MatchNodeBuilder.b
uildNode(MatchNodeBuilder.java:76)
at org.apache.cocoon.components.treeprocessor.sitemap.PipelineNodeBuilde
r.buildNode(PipelineNodeBuilder.java:113)
at org.apache.cocoon.components.treeprocessor.sitemap.PipelinesNodeBuild
er.buildNode(PipelinesNodeBuilder.java:65)
at org.apache.cocoon.components.treeprocessor.sitemap.SitemapNodeBuilder
.buildNode(SitemapNodeBuilder.java:70)
at org.apache.cocoon.components.treeprocessor.DefaultTreeBuilder.createT
ree(DefaultTreeBuilder.java:296)
at org.apache.cocoon.components.treeprocessor.DefaultTreeBuilder.build(D
efaultTreeBuilder.java:381)
at org.apache.cocoon.components.treeprocessor.TreeProcessor.buildConcret
eProcessor(TreeProcessor.java:401)
at org.apache.cocoon.components.treeprocessor.TreeProcessor.setupConcret
eProcessor(TreeProcessor.java:348)
at org.apache.cocoon.components.treeprocessor.TreeProcessor.process(Tree
Processor.java:247)
at org.apache.cocoon.components.treeprocessor.sitemap.MountNode.invoke(M
ountNode.java:112)
at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNo
de.invokeNodes(AbstractParentProcessingNode.java:76)
at org.apache.cocoon.components.treeprocessor.sitemap.SelectNode.invoke(
SelectNode.java:82)
at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNo
de.invokeNodes(AbstractParentProcessingNode.java:76)
at org.apache.cocoon.components.treeprocessor.sitemap.PipelineNode.invok
e(PipelineNode.java:138)
at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNo
de.invokeNodes(AbstractParentProcessingNode.java:76)
at org.apache.cocoon.components.treeprocessor.sitemap.PipelinesNode.invo
ke(PipelinesNode.java:95)
at org.apache.cocoon.components.treeprocessor.ConcreteTreeProcessor.proc
ess(ConcreteTreeProcessor.java:203)
at org.apache.cocoon.components.treeprocessor.ConcreteTreeProcessor.proc
ess(ConcreteTreeProcessor.java:149)
at org.apache.cocoon.components.treeprocessor.TreeProcessor.process(Tree
Processor.java:248)
at org.apache.cocoon.components.treeprocessor.sitemap.MountNode.invoke(M
ountNode.java:112)
at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNo
de.invokeNodes(AbstractParentProcessingNode.java:76)
at org.apache.cocoon.components.treeprocessor.sitemap.SelectNode.invoke(
SelectNode.java:82)
at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNo
de.invokeNodes(AbstractParentProcessingNode.java:76)
at org.apache.cocoon.components.treeprocessor.sitemap.PipelineNode.invok
e(PipelineNode.java:138)
at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNo
de.invokeNodes(AbstractParentProcessingNode.java:76)
at org.apache.cocoon.components.treeprocessor.sitemap.PipelinesNode.invo
ke(PipelinesNode.java:95)
at org.apache.cocoon.components.treeprocessor.ConcreteTreeProcessor.proc
ess(ConcreteTreeProcessor.java:203)
at org.apache.cocoon.components.treeprocessor.ConcreteTreeProcessor.proc
ess(ConcreteTreeProcessor.java:149)
at org.apache.cocoon.components.treeprocessor.TreeProcessor.process(Tree
Processor.java:248)
at org.apache.cocoon.Cocoon.process(Cocoon.java:503)
at org.apache.cocoon.bean.CocoonWrapper.getPage(CocoonWrapper.java:456)
at org.apache.cocoon.bean.CocoonBean.processTarget(CocoonBean.java:501)
at org.apache.cocoon.bean.CocoonBean.process(CocoonBean.java:362)
at org.apache.cocoon.Main.main(Main.java:321)
Caused by: org.apache.cocoon.sitemap.PatternException: Cannot get module named '
lm' in expression '{lm:project.{1}{2}.pdf}'
at org.apache.cocoon.components.treeprocessor.variables.PreparedVariable
Resolver.getNewModuleToken(PreparedVariableResolver.java:142)
at org.apache.cocoon.components.treeprocessor.variables.PreparedVariable
Resolver.access$500(PreparedVariableResolver.java:41)
at org.apache.cocoon.components.treeprocessor.variables.PreparedVariable
Resolver$1.addToken(PreparedVariableResolver.java:96)
at org.apache.cocoon.components.treeprocessor.variables.VariableExpressi
onTokenizer.tokenize(VariableExpressionTokenizer.java:95)
at org.apache.cocoon.components.treeprocessor.variables.PreparedVariable
Resolver.<init>(PreparedVariableResolver.java:69)
at org.apache.cocoon.components.treeprocessor.variables.VariableResolver
Factory.getResolver(VariableResolverFactory.java:104)
at org.apache.cocoon.components.treeprocessor.sitemap.SelectNodeBuilder.
buildNode(SelectNodeBuilder.java:59)
at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNo
deBuilder.buildChildNodesList(AbstractParentProcessingNodeBuilder.java:121)
... 35 more
Caused by: org.apache.avalon.framework.service.ServiceException: Could not find
component for role: [org.apache.cocoon.components.modules.input.InputModule/lm]
(Key='org.apache.cocoon.components.modules.input.InputModule/lm')
at org.apache.cocoon.core.container.CoreServiceManager.lookup(CoreServic
eManager.java:364)
at org.apache.cocoon.core.container.DefaultServiceSelector.select(Defaul
tServiceSelector.java:138)
at org.apache.cocoon.components.treeprocessor.variables.PreparedVariable
Resolver.getNewModuleToken(PreparedVariableResolver.java:140)
X [0] linkmap.html BROKEN: URI not found: E
rror while creating node 'select' at file:/D:/apache-forrest-0.7/build/plugins/o
rg.apache.forrest.plugin.output.pdf/output.xmap:28:35
... 42 more
Logging Error: Writing event to closed stream.
Total time: 0 minutes 1 seconds, Site size: 0 Site pages: 1

Thanks.

[1] http://xml.apache.org/commons/howto-forrest.html

Michael Glavassevich XML Parser Development IBM Toronto Lab E-mail: mrglavas@...
E-mail: mrglavas@...

[VOTE RESULTS]: xml-commons-external 1.4.01, 1.3.05, 1.2.06 Releases on Tuesday, December 15th

2009-12-14T23:01:46Z

The vote to release xml-commons-external 1.4.01, 1.3.05 and 1.2.06 resulted in 6 +1 votes (3 from Xerces PMC members, 3 from other committers) and no other votes:

+1 by:
- David Cargill (PMC)
- Mukul Gandhi
- Michael Glavassevich (PMC)
- Hiranya Jayathilaka
- Khaled Noaman
- Gareth Reakes (PMC)

The releases should be up on the mirror sites some time today.

Thanks.

Michael Glavassevich XML Parser Development IBM Toronto Lab E-mail: mrglavas@...
E-mail: mrglavas@...

Michael Glavassevich <mrglavas@...> wrote on 12/11/2009 09:35:02 AM: > Hi all, > > Xerces-J is planning to have its first release [1] in over two years > next week. So that Xerces-J 2.10.0 can pick-up the JAXP 1.4 APIs > from XML Commons I propose that we release xml-commons-external-1.4. > 01 on Tuesday, December 15th and while we're at it also release xml- > commons-external-1.2.06 and xml-commons-external-1.3.05 which have > been in the queue for quite some time. > > I've uploaded release candidates to people.apache.org [2] for > review. The change summary is available in status.xml here [3] in SVN. > > To start, here's my +1. > > Thanks. > > [1] http://markmail.org/thread/wjvplpmevpex7qoz > [2] http://people.apache.org/builds/xml-commons/ > [3] http://svn.apache.org/repos/asf/xml/commons/trunk/status.xml > > Michael Glavassevich > XML Parser Development > IBM Toronto Lab > E-mail: mrglavas@... > E-mail: mrglavas@...

Re: [VOTE]: xml-commons-external 1.4.01, 1.3.05, 1.2.06 Releases on Tuesday, December 15th

2009-12-14T06:54:53Z

+1

Regards,
David A. Cargill
XML Parser Development
IBM Toronto Lab
(905) 413-2371, tie 313
cargilld@...
Michael Glavassevich/Toronto/IBM@IBMCA

Michael Glavassevich/Toronto/IBM@IBMCA

12/11/2009 09:35 AM

To	commons-dev@...
cc	j-dev@..., private@..., boris@...
Subject	[VOTE]: xml-commons-external 1.4.01, 1.3.05, 1.2.06 Releases on Tuesday, December 15th

Hi all,
Xerces-J is planning to have its first release [1] in over two years next week. So that Xerces-J 2.10.0 can pick-up the JAXP 1.4 APIs from XML Commons I propose that we release xml-commons-external-1.4.01 on Tuesday, December 15th and while we're at it also release xml-commons-external-1.2.06 and xml-commons-external-1.3.05 which have been in the queue for quite some time.
I've uploaded release candidates to people.apache.org [2] for review. The change summary is available in status.xml here [3] in SVN.
To start, here's my +1.
Thanks.
[1]http://markmail.org/thread/wjvplpmevpex7qoz[2]http://people.apache.org/builds/xml-commons/[3]http://svn.apache.org/repos/asf/xml/commons/trunk/status.xml
Michael Glavassevich XML Parser Development IBM Toronto Lab E-mail: mrglavas@... E-mail: mrglavas@...

pic08273.gif (1K) Download Attachment

Re: [VOTE]: xml-commons-external 1.4.01, 1.3.05, 1.2.06 Releases on Tuesday, December 15th

2009-12-11T06:41:44Z

Gareth

On 11 Dec 2009, at 14:35, Michael Glavassevich wrote:

Hi all,

Xerces-J is planning to have its first release [1] in over two years next week. So that Xerces-J 2.10.0 can pick-up the JAXP 1.4 APIs from XML Commons I propose that we release xml-commons-external-1.4.01 on Tuesday, December 15th and while we're at it also release xml-commons-external-1.2.06 and xml-commons-external-1.3.05 which have been in the queue for quite some time.

I've uploaded release candidates to people.apache.org [2] for review. The change summary is available in status.xml here [3] in SVN.

To start, here's my +1.

Thanks.

[1] http://markmail.org/thread/wjvplpmevpex7qoz
[2] http://people.apache.org/builds/xml-commons/
[3] http://svn.apache.org/repos/asf/xml/commons/trunk/status.xml

Michael Glavassevich XML Parser Development IBM Toronto Lab E-mail: mrglavas@...
E-mail: mrglavas@...

--
Gareth Reakes, CTO WE7 - Great Music, Free
+44-20-7117-0809 http://www.we7.com

[VOTE]: xml-commons-external 1.4.01, 1.3.05, 1.2.06 Releases on Tuesday, December 15th

2009-12-11T06:35:02Z

Hi all,

Xerces-J is planning to have its first release [1] in over two years next week. So that Xerces-J 2.10.0 can pick-up the JAXP 1.4 APIs from XML Commons I propose that we release xml-commons-external-1.4.01 on Tuesday, December 15th and while we're at it also release xml-commons-external-1.2.06 and xml-commons-external-1.3.05 which have been in the queue for quite some time.

I've uploaded release candidates to people.apache.org [2] for review. The change summary is available in status.xml here [3] in SVN.

To start, here's my +1.

Thanks.

[1] http://markmail.org/thread/wjvplpmevpex7qoz
[2] http://people.apache.org/builds/xml-commons/
[3] http://svn.apache.org/repos/asf/xml/commons/trunk/status.xml

Michael Glavassevich XML Parser Development IBM Toronto Lab E-mail: mrglavas@...
E-mail: mrglavas@...

DO NOT REPLY [Bug 48194] Xml Catalog Resovler fails with included schemas

2009-11-20T09:48:29Z

https://issues.apache.org/bugzilla/show_bug.cgi?id=48194

Robert Streich <robert.streich@...> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |robert.streich@...

--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

DO NOT REPLY [Bug 48194] Xml Catalog Resovler fails with included schemas

2009-11-16T10:13:19Z

https://issues.apache.org/bugzilla/show_bug.cgi?id=48194

--- Comment #2 from Robert Streich <robert.streich@...> 2009-11-16 10:13:18 UTC ---
Created an attachment (id=24543)
--> (https://issues.apache.org/bugzilla/attachment.cgi?id=24543)
Simple set up with included/imported schemas to illustrate bug.

--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

DO NOT REPLY [Bug 48194] Xml Catalog Resovler fails with included schemas

2009-11-13T14:47:52Z

https://issues.apache.org/bugzilla/show_bug.cgi?id=48194

--- Comment #1 from Robert Streich <robert.streich@...> 2009-11-13 14:47:52 UTC ---
I don't know if this is viable, but this works:

// The namespace is useful for resolving namespace aware
// grammars such as XML schema. Let it take precedence over
// the external identifier if one exists.
String namespace = resourceIdentifier.getNamespace();
if (namespace != null) {
if (resourceIdentifier instanceof XSDDescription
&& XSDDescription.CONTEXT_INCLUDE == ((XSDDescription)
resourceIdentifier).getContextType()) {
resolvedId =
resolveSystem(resourceIdentifier.getLiteralSystemId());
} else {
resolvedId = resolveURI(namespace);
}
}

--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

DO NOT REPLY [Bug 48194] New: Xml Catalog Resovler fails with included schemas

2009-11-13T12:43:49Z

https://issues.apache.org/bugzilla/show_bug.cgi?id=48194

Summary: Xml Catalog Resovler fails with included schemas
Product: XmlCommons
Version: 1.x
Platform: PC
OS/Version: Windows Vista
Status: NEW
Severity: normal
Priority: P2
Component: Resolver
AssignedTo: commons-dev@...
ReportedBy: robert.streich@...

If you attempt to include a schema into one that has a targetNamespace,
it fails to correctly resolve the included component. The problem is
with line ~420 of XMLCatalogResolver:

// The namespace is useful for resolving namespace aware
// grammars such as XML schema. Let it take precedence over
// the external identifier if one exists.
String namespace = resourceIdentifier.getNamespace();
if (namespace != null) {
resolvedId = resolveURI(namespace);
}

--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

November Board Report

2009-11-08T20:30:08Z

Hi all,

The November board meeting is coming up on the 18th and we're due to report. The Wiki page for the report is set up here: http://wiki.apache.org/xerces/November2009. As usual I'll cover Xerces-J and XML Commons. Could other committers please fill in the status for Xerces-C and Xerces-P. Thanks.

Michael Glavassevich XML Parser Development IBM Toronto Lab E-mail: mrglavas@...
E-mail: mrglavas@...

assistance with Apache Forrest

2009-11-01T19:56:56Z

I did some research to find the ASF projects that
manage their websites with Apache Forrest, and am
sending similar email to each project's dev mail list.
Already sent to general at xerces and general at xml,
but duplicates will not hurt.

The purposes of this email are to remind people
about some of the useful facilities of Forrest,
and also alert them to discussion about the status
and future directions of Forrest, and to appeal for
people to assist Forrest.

--- oOo ---

These are useful facilities to assist with developing
and managing a Forrest solution for your project's website.

"How to deploy documentation with the Forrestbot
svn workstage"
This explains how the Forrest project manages our
own documentation.
http://forrest.apache.org/howto-forrestbot-svn.html

"Generate an ASF mirrors page using interactive web form"
http://forrest.apache.org/docs/dev/howto/howto-asf-mirror.html

"ForrestBar - Firefox toolbar to ease navigation
and search of Forrest resources"
http://forrest.apache.org/tools/forrestbar.html

"How to do development with Apache Forrest"
http://forrest.apache.org/howto-dev.html

"Frequently Asked Questions"
http://forrest.apache.org/faq.html

"The Anakia output plugin"
This was developed to assist the old Incubator
website to stop using Forrest and export all content
to an Anakia "xdoc" format. From there it could used
by an Anakia-based build system, or be further transformed.
http://forrest.apache.org/pluginDocs/plugins_0_80/org.apache.forrest.plugin.output.Anakia/

As usual, if you need further assistance with anything
then please ask on the Forrest mail lists.

--- oOo ---

There is discussion currently underway on the Forrest
dev mail list about the current status and future
direction of Forrest.
http://thread.gmane.org/gmane.text.xml.forrest.devel/27325

If anyone can assist Forrest, in any capacity, then
please do.

-David

Re: resolver should be able to parse catalog files without needing to resolve external entities?

2009-10-29T14:10:39Z

Jack,

Jack Bates <ms419@...> wrote on 10/28/2009 07:48:23 PM: > On Sat, 2009-10-24 at 15:10 -0400, Michael Glavassevich wrote: > > The OASIS catalog DTD is included in resolver.jar and there is a > > BootstrapResolver [1] which gets installed on the parser that reads > > the catalog which can return this DTD. I'm sure the reason that isn't > > happening is that the public and system IDs differ from the ones that > > the resolver knows about. You're supposed to extend BootstrapResolver > > (in your own application) if you need support for more than the > > well-known public IDs and URIs for the catalog DTDs / schemas and set > > an instance of this extension on the CatalogManager [2]. > > Thank you Michael! After some more digging, I think the reason that the > w3c-dtd-xhtml catalog.xml isn't using the well known catalog DTD public > ID and URI, > > <!DOCTYPE catalog PUBLIC "-//OASIS//DTD XML Catalogs V1.0//EN" > "http://www.oasis-open.org/committees/entity/release/1.0/catalog.dtd"> > > is that it's trying to use a different DTD? > > <!DOCTYPE catalog PUBLIC "-//GlobalTransCorp//DTD XML Catalogs V1.0- > Based Extension V1.0//EN" > "http://globaltranscorp.org/oasis/catalog/xml/tr9401.dtd"> > > The xml-core package distributes "tr9401.dtd", in addition to > "catalog.dtd" - here it is, > http://www.sfu.ca/~jdbates/tmp/debian/200910280/tr9401.dtd > > - and here are the differences between it, and the "catalog.dtd" > included in resolver.jar, > http://www.sfu.ca/~jdbates/tmp/debian/200910280/diff > > I dunno if the w3c-dtd-xhtml catalog.xml actually requires this > different DTD, but it sounds like if it does, and the system ID isn't > accessible, then it will only be parsable by tools which extend > BootstrapResolver to add support for this different DTD?

That's what I would do. I could imagine extending BootstrapResolver so that it uses a secondary catalog resolver so that you just update a catalog file instead of the code when you need a redirect for yet another catalog DTD.

Thanks.

Michael Glavassevich XML Parser Development IBM Toronto Lab E-mail: mrglavas@...
E-mail: mrglavas@...

Re: resolver should be able to parse catalog files without needing to resolve external entities?

2009-10-28T16:48:23Z

On Sat, 2009-10-24 at 15:10 -0400, Michael Glavassevich wrote:
> The OASIS catalog DTD is included in resolver.jar and there is a
> BootstrapResolver [1] which gets installed on the parser that reads
> the catalog which can return this DTD. I'm sure the reason that isn't
> happening is that the public and system IDs differ from the ones that
> the resolver knows about. You're supposed to extend BootstrapResolver
> (in your own application) if you need support for more than the
> well-known public IDs and URIs for the catalog DTDs / schemas and set
> an instance of this extension on the CatalogManager [2].

Thank you Michael! After some more digging, I think the reason that the
w3c-dtd-xhtml catalog.xml isn't using the well known catalog DTD public
ID and URI,

<!DOCTYPE catalog PUBLIC "-//OASIS//DTD XML Catalogs V1.0//EN"
"http://www.oasis-open.org/committees/entity/release/1.0/catalog.dtd">

is that it's trying to use a different DTD?

<!DOCTYPE catalog PUBLIC "-//GlobalTransCorp//DTD XML Catalogs V1.0-Based Extension V1.0//EN"
"http://globaltranscorp.org/oasis/catalog/xml/tr9401.dtd">

The xml-core package distributes "tr9401.dtd", in addition to
"catalog.dtd" - here it is,
http://www.sfu.ca/~jdbates/tmp/debian/200910280/tr9401.dtd

- and here are the differences between it, and the "catalog.dtd"
included in resolver.jar,
http://www.sfu.ca/~jdbates/tmp/debian/200910280/diff

I dunno if the w3c-dtd-xhtml catalog.xml actually requires this
different DTD, but it sounds like if it does, and the system ID isn't
accessible, then it will only be parsable by tools which extend
BootstrapResolver to add support for this different DTD?

Re: resolver should be able to parse catalog files without needing to resolve external entities?

2009-10-24T12:10:58Z

The OASIS catalog DTD is included in resolver.jar and there is a BootstrapResolver [1] which gets installed on the parser that reads the catalog which can return this DTD. I'm sure the reason that isn't happening is that the public and system IDs differ from the ones that the resolver knows about. You're supposed to extend BootstrapResolver (in your own application) if you need support for more than the well-known public IDs and URIs for the catalog DTDs / schemas and set an instance of this extension on the CatalogManager [2].

Thanks.

[1] http://xml.apache.org/commons/components/apidocs/resolver/org/apache/xml/resolver/helpers/BootstrapResolver.html
[2] http://xml.apache.org/commons/components/apidocs/resolver/org/apache/xml/resolver/CatalogManager.html#setBootstrapResolver(org.apache.xml.resolver.helpers.BootstrapResolver)

Michael Glavassevich XML Parser Development IBM Toronto Lab E-mail: mrglavas@...
E-mail: mrglavas@...

Earl Hood <earl@...> wrote on 10/24/2009 01:22:50 PM: > On October 23, 2009 at 17:19, someone wrote: > > > Here's an example of a catalog.xml file distributed in the Debian and > > Ubuntu w3c-dtd-xhtml package, > > http://www.sfu.ca/~jdbates/tmp/debian/200910230/catalog.xml > > > > It starts with, > > > > <?xml version='1.0'?> > > <!DOCTYPE catalog PUBLIC "-//GlobalTransCorp//DTD XML Catalogs V1.0-Based > > <Extension V1.0//EN" > > "http://globaltranscorp.org/oasis/catalog/xml/tr9401.dtd";> > > [...] > > I think they should fix it so the system identifier is set > to a pathname on the local file system. > > Also, the public identifier used is not the standard public > identifier, "-//OASIS//DTD XML Catalogs V1.1//EN". So even > if the resolver provided intrinsic recognition of > the "-//OASIS//DTD XML Catalogs V1.1//EN" identifier, it > would still be of no use in this case. > > One can argue that the w3c-dtd-xhtml package has a bug in > their distribution since it provides no facility to resolve > the DTD to the local file system. The system identifier > should be set to the pathname the catalog DTD is placed > by the w3c-dtd-xhtml installer. > > > I understand comment #4, > > https://bugs.launchpad.net/ubuntu/+source/w3c-dtd- > xhtml/+bug/400259/comments/4 > > > > - to be suggesting that org.apache.xml.resolver is not following the > > encouragement of, > > http://www.oasis-open.org/committees/download.php/14809/xml- > catalogs.html#s.bootstrap > > > > "Implementations are encouraged to provide some sort of bootstrapping > > functionality to resolve external identifiers and URIs that the > > implementation needs to load catalog entry files. > > It is not a requirement: > > Conformant processors are not required to be able to perform > resolution of those identifiers through the XML Catalog. > > The word "should" is used in other text instead of "must". Also, > the following is stated: > > Users can avoid any problems that might arise by limiting the > external identifiers and URIs used to those that do not need > resolution. Note that this only applies to external identifiers and > URIs that must be resolved in order to load the catalog entry file. > > > - and to be suggesting that not following this encouragement is a bug > > > > Is maybe my understanding wrong - or either of these suggestions wrong? > > The recommendations of the Oasis document are beneficial, but > they are only recommendations, not requirements. So the "bug" > reports are really enhancement requests. > > IMO, the work-around for the problem is easy, and is directly > suggested by the Oasis document: Use system identifiers that > are resolvable without the need of a catalog. > > I think the underlying technical problem of why the resolver library > does not provide intrinsic resolution of the catalog DTD is that > the library does not know where the DTD may be installed for any > system that uses the resolver. Since other software systems include > the resolver in their distribution, the DTD itself may not even > be available. > > A possible method of always knowing how to find the catalog DTD is > for the resolver to include the DTD in the resolver.jar file itself. > The resolver could register a custom (internal) resolver to the XML > parser when reading catalog files so any references to the DTD can > be resolved via a classpath resource lookup. IMO, I'm not sure it > is worth the effort to do this when simple work-arounds exist for > the problem. > > I'm sure patches are welcome if anyone wants to implement this > functionality. > > --ewh

Re: resolver should be able to parse catalog files without needing to resolve external entities?

2009-10-24T10:22:50Z

On October 23, 2009 at 17:19, someone wrote:

> Here's an example of a catalog.xml file distributed in the Debian and
> Ubuntu w3c-dtd-xhtml package,
> http://www.sfu.ca/~jdbates/tmp/debian/200910230/catalog.xml
>
> It starts with,
>
> <?xml version='1.0'?>
> <!DOCTYPE catalog PUBLIC "-//GlobalTransCorp//DTD XML Catalogs V1.0-Based
> <Extension V1.0//EN"
> "http://globaltranscorp.org/oasis/catalog/xml/tr9401.dtd";>
> [...]

I think they should fix it so the system identifier is set
to a pathname on the local file system.

Also, the public identifier used is not the standard public
identifier, "-//OASIS//DTD XML Catalogs V1.1//EN". So even
if the resolver provided intrinsic recognition of
the "-//OASIS//DTD XML Catalogs V1.1//EN" identifier, it
would still be of no use in this case.

One can argue that the w3c-dtd-xhtml package has a bug in
their distribution since it provides no facility to resolve
the DTD to the local file system. The system identifier
should be set to the pathname the catalog DTD is placed
by the w3c-dtd-xhtml installer.

> I understand comment #4,
> https://bugs.launchpad.net/ubuntu/+source/w3c-dtd-xhtml/+bug/400259/comments/4
>
> - to be suggesting that org.apache.xml.resolver is not following the
> encouragement of,
> http://www.oasis-open.org/committees/download.php/14809/xml-catalogs.html#s.bootstrap
>
> "Implementations are encouraged to provide some sort of bootstrapping
> functionality to resolve external identifiers and URIs that the
> implementation needs to load catalog entry files.

It is not a requirement:

Conformant processors are not required to be able to perform
resolution of those identifiers through the XML Catalog.

The word "should" is used in other text instead of "must". Also,
the following is stated:

Users can avoid any problems that might arise by limiting the
external identifiers and URIs used to those that do not need
resolution. Note that this only applies to external identifiers and
URIs that must be resolved in order to load the catalog entry file.

> - and to be suggesting that not following this encouragement is a bug
>
> Is maybe my understanding wrong - or either of these suggestions wrong?

The recommendations of the Oasis document are beneficial, but
they are only recommendations, not requirements. So the "bug"
reports are really enhancement requests.

IMO, the work-around for the problem is easy, and is directly
suggested by the Oasis document: Use system identifiers that
are resolvable without the need of a catalog.

I think the underlying technical problem of why the resolver library
does not provide intrinsic resolution of the catalog DTD is that
the library does not know where the DTD may be installed for any
system that uses the resolver. Since other software systems include
the resolver in their distribution, the DTD itself may not even
be available.

A possible method of always knowing how to find the catalog DTD is
for the resolver to include the DTD in the resolver.jar file itself.
The resolver could register a custom (internal) resolver to the XML
parser when reading catalog files so any references to the DTD can
be resolved via a classpath resource lookup. IMO, I'm not sure it
is worth the effort to do this when simple work-arounds exist for
the problem.

I'm sure patches are welcome if anyone wants to implement this
functionality.

--ewh

Re: resolver should be able to parse catalog files without needing to resolve external entities?

2009-10-23T14:47:00Z

On October 23, 2009 at 09:52, Jack Bates wrote:

> I'm getting the following exception using the XML catalog resolver with
> FOP,

> DELEGATE_PUBLIC: -//W3C//DTD XHTML//EN
> file:/usr/share/xml/xhtml/schema/dtd/catalog.xml
> resolvePublic(-//W3C//DTD XHTML 1.0 Transitional//EN,null)
> Switching to delegated catalog(s):
> file:/usr/share/xml/xhtml/schema/dtd/1.0/catalog.xml
> Parse catalog: file:/usr/share/xml/xhtml/schema/dtd/1.0/catalog.xml
> Loading catalog: file:/usr/share/xml/xhtml/schema/dtd/1.0/catalog.xml
> Default BASE: file:/usr/share/xml/xhtml/schema/dtd/1.0/catalog.xml
> 22-Oct-2009 5:04:13 PM org.apache.fop.cli.Main startFOP
> SEVERE: Exception
> javax.xml.transform.TransformerException: java.net.UnknownHostException:
> globaltranscorp.org

Is globaltranscorp.org resolvable on the system you are running FOP?
Apparently the underlying network library of the JVM cannot resolve
the hostname.

As for the "resolve external entities" problem, it appears to
be a chicken-n-egg problem. The resolver depends on the underlying
XML parser to parse the XML catalog file, but at that time,
the base entity resolution of the XML parser is being used since
the resolver is still bootstrapping itself.

If your catalog file contains a DOCTYPE declaration with a public and
system identifier, then the XML parser will try to resolve it, and if
the system identifier listed is not accessible, you will get an error.

All of this is a function of the XML parser itself and NOT the
resolver library.

In practice, I normally do not specify a doctype declaration for
catalog files to avoid the unnecessary overhead of parsing a DTD.

If you absolutely need to have DTD validation of your catalog files,
make sure the system identifier is resolvable, and preferably to a
location on the local file system for better performance and to avoid
dependency on a remote system.

--ewh

resolver should be able to parse catalog files without needing to resolve external entities?

2009-10-23T09:52:22Z

I'm getting the following exception using the XML catalog resolver with
FOP,

[...]
DELEGATE_PUBLIC: -//W3C//DTD XHTML//EN
file:/usr/share/xml/xhtml/schema/dtd/catalog.xml
resolvePublic(-//W3C//DTD XHTML 1.0 Transitional//EN,null)
Switching to delegated catalog(s):
file:/usr/share/xml/xhtml/schema/dtd/1.0/catalog.xml
Parse catalog: file:/usr/share/xml/xhtml/schema/dtd/1.0/catalog.xml
Loading catalog: file:/usr/share/xml/xhtml/schema/dtd/1.0/catalog.xml
Default BASE: file:/usr/share/xml/xhtml/schema/dtd/1.0/catalog.xml
22-Oct-2009 5:04:13 PM org.apache.fop.cli.Main startFOP
SEVERE: Exception
javax.xml.transform.TransformerException: java.net.UnknownHostException: globaltranscorp.org
at org.apache.fop.cli.InputHandler.transformTo(InputHandler.java:314)
at org.apache.fop.cli.InputHandler.renderTo(InputHandler.java:146)
at org.apache.fop.cli.Main.startFOP(Main.java:174)
at org.apache.fop.cli.Main.main(Main.java:205)
[...]

I think it's the same issue reported here,
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=491091

- and here,
https://bugs.launchpad.net/ubuntu/+source/w3c-dtd-xhtml/+bug/400259

Is comment #4 correct?

"Arguably this is a bug in org.apache.xml.resolver, cf.
http://www.oasis-open.org/committees/download.php/14809/xml-catalogs.html#s.bootstrap - the resolver should be able to parse catalog files without needing to resolve external entities"

https://bugs.launchpad.net/ubuntu/+source/w3c-dtd-xhtml/+bug/400259/comments/4

Re: Proposal - A Very Simple API for Reading Simple XML Data

2009-09-08T04:35:46Z

After stumbling upon this answer I thought I'd do the conversion and compare the two approaches.

I happened to have used the original posters method but didn't like it because it seemed to move the persistence meta-data out of the model and into an external adapter. Some people may like that, but I prefer to have the persistence meta-data in the form of annotations right next to the model (or DTO if you prefer).

So I made the conversion and using XStream I was able to remove vast tracts of marshalling code and condense it into a a single 3 line templated method in a base class. All the mapping information is now held in simple to understand annotations, and specialised date handling is managed through an XStream converter.

Now for the all important performance figures. In my particular configuration that requires a *lot* of XML parsing and mucking about with various InputStreams, XStream came out on top - which is a relief given the benefits that it brings. The times to completion were:

Traditional XML through DocumentFactory and Node analysis=32s
XStream=26s

Not a vast difference (~20%) but enough to justify XStream as the better way to go.

Hope this helps someone.

Gary

Bruno Borges wrote:

Try XStream. :-)

Cheers,
Bruno

DO NOT REPLY [Bug 47720] New: Find Catalogs using Service Provider Interface

2009-08-21T03:00:14Z

https://issues.apache.org/bugzilla/show_bug.cgi?id=47720

Summary: Find Catalogs using Service Provider Interface
Product: XmlCommons
Version: 1.x
Platform: All
OS/Version: All
Status: NEW
Severity: enhancement
Priority: P2
Component: Resolver
AssignedTo: commons-dev@...
ReportedBy: Martin.vGagern@...

--- Comment #0 from Martin von Gagern <Martin.vGagern@...> 2009-08-21 03:00:04 PDT ---
Developing apps would be greatly simplified if you could simply add some JAR to
the classpath, and a Catalog as generated by the default CatalogManager would
find the catalog within that JAR as well as the documents it references.

To achieve this, I believe a slightly modified version of the Service Provider
Interface would be most suitable.
http://java.sun.com/j2se/1.5.0/docs/guide/jar/jar.html#Service%20Provider
describes that a file under META-INF/services/package.interface.Name should
list qualified names of classes providing said interface.

To work with XML catalogs, you would specify a class name, but instead the name
of a resource. So I think that you should have a file called
"META-INF/services/org.apache.xml.resolver.catalog" which would contain lines
like "my/company/catalog.xml". That catalog could then be located as a
resource, auto-appended to the list of catalogs and parsed along with the
system catalogs.

One could consider placing the catalog itself in the META-INF directory. That,
however, would probably prevent it from being uniquely identified by its name
alone, which might be useful if you want to deal with the catalog yourself,
without using the full CatalogManager framework.

--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

August Board Report

2009-08-16T08:54:27Z

Hey all,

According to the calendar the August board meeting is happening this Wednesday and we're due to report again. The page for the report is setup on the Wiki here: http://wiki.apache.org/xerces/August2009. As usual I'll cover Xerces-J and XML Commons. Could other committers please fill in the status for Xerces-C and Xerces-P.

Thanks.

Michael Glavassevich XML Parser Development IBM Toronto Lab E-mail: mrglavas@...
E-mail: mrglavas@...

DO NOT REPLY [Bug 47671] unable to resolve a relative path

2009-08-11T08:00:06Z

https://issues.apache.org/bugzilla/show_bug.cgi?id=47671

--- Comment #3 from Earl Hood <earl@...> 2009-08-11 08:00:03 PDT ---
(In reply to comment #2)
> resolveSystem(file:/files/erlang/module.xsl)
> resolveSystem(file:/files/erlang/erlang.xml)
> resolveSystem(file:/files/erlang/erlref.dtd)

The above verbosity implies (to me) that the parser is passing
the wrong system ID to the resolver.

I.e. Instead of the XML parser passing just "erlref.dtd" to
the resolver, the parser is first fully qualifying the system ID
(probably based upon the current working directory)
before it passes the system ID to the resolver. Since the
catalog has no entry for "file:/files/erlang/erlref.dtd", the
resolver will find no matching entries.

The parser then attempts to load the file directory, which of
course fails since the file does not exist with given path.

At this time, this appears to be an XML parser problem.
The parser should only be passing "erlref.dtd" to the
resolver.

BTW, did you trim some of the diagnostic output? It seems
the XML parser is calling Catalog directly versus the
CatalogResolver class that implements the SAX EntityResolver
and JAXP URIResolver interfances. I see no debugging messages
from the CatalogResolver class.

--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

DO NOT REPLY [Bug 47671] unable to resolve a relative path

2009-08-10T21:53:37Z

https://issues.apache.org/bugzilla/show_bug.cgi?id=47671

--- Comment #2 from Dave Pawson <dave.pawson@...> 2009-08-10 21:53:34 PDT ---
What is the full catalog?
Does the path "/files/erlang/dtds/erlref.dtd" exist on
the filesystem? Or have you set xml:base?

Have you tried setting the verbosity with the
xml.catalog.verbosity property. Set to 5 or larger to get maximum
verbosity. This will determine if your catalog is actually getting
read and what the resolver does when resolving a uri.

What is the exact error message(s) you get?

If you can provide a reproducable test case, it will make
finding a solution faster.

1. full catalog

<?xml version="1.0" encoding="utf-8"?>
<catalog xmlns="urn:oasis:names:tc:entity:xmlns:xml:catalog"
>
<system
systemId="erlref.dtd"
uri="/files/erlang/dtds/erlref.dtd" />
<systemSuffix
systemIdSuffix="xhtml-lat1.ent"
uri="/files/erlang/dtds/xhtml-lat1.ent" />
</catalog>

2. The dtd and entity file are in ./dtds /files/erlang/dtds
3. I had tried xml:base, but now removed.

Instance has
<?xml version="1.0" encoding="latin1" ?>
<!DOCTYPE erlref SYSTEM "erlref.dtd">
a file of
<erlref> </erlref>

would test it.

I have CatalogManger.properties with verbosity set high.

Error reported is:

Parse catalog: erlang.catalog.xml
Loading catalog: erlang.catalog.xml
Default BASE: file:////files/erlang/erlang.catalog.xml
system: erlref.dtd
/files/erlang/dtds/erlref.dtd
SYSTEM: erlref.dtd
file:/files/erlang/dtds/erlref.dtd
systemSuffix: xhtml-lat1.ent
/files/erlang/dtds/xhtml-lat1.ent
SYSTEM_SUFFIX: xhtml-lat1.ent
file:/files/erlang/dtds/xhtml-lat1.ent
resolveSystem(file:/files/erlang/module.xsl)
resolveSystem(file:/files/erlang/erlang.xml)
resolveSystem(file:/files/erlang/erlref.dtd)
Error on line 2 column 37 of file:/files/erlang/erlang.xml:
Error reported by XML parser: Cannot read from file:/files/erlang/erlref.dtd
(/files/erlang/erlref.dtd (No such file or directory))
Transformation failed: Run-time errors were reported

HTH

--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

DO NOT REPLY [Bug 47671] unable to resolve a relative path

2009-08-10T16:27:33Z

https://issues.apache.org/bugzilla/show_bug.cgi?id=47671

Earl Hood <earl@...> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |earl@...

--- Comment #1 from Earl Hood <earl@...> 2009-08-10 16:27:31 PDT ---
What is the full catalog?
Does the path "/files/erlang/dtds/erlref.dtd" exist on
the filesystem? Or have you set xml:base?

Have you tried setting the verbosity with the
xml.catalog.verbosity property. Set to 5 or larger to get maximum
verbosity. This will determine if your catalog is actually getting
read and what the resolver does when resolving a uri.

What is the exact error message(s) you get?

If you can provide a reproducable test case, it will make
finding a solution faster.

BTW, I'm not an official maintainer of the resolver code,
but I had to dive into it over a year ago to fix bugs.
I believe some of my patches have been accepted, but
I do not think a new release of the resolver has been
done in quite some time.

--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.