You are viewing a plain text version of this content. The canonical link for it is here.
Posted to fop-commits@xmlgraphics.apache.org by je...@apache.org on 2008/07/12 14:19:40 UTC
svn commit: r676161 -
/xmlgraphics/fop/trunk/src/java/org/apache/fop/events/model/EventModel.java
Author: jeremias
Date: Sat Jul 12 05:19:40 2008
New Revision: 676161
URL: http://svn.apache.org/viewvc?rev=676161&view=rev
Log:
Attempt to fix a potential build problem.
Modified:
xmlgraphics/fop/trunk/src/java/org/apache/fop/events/model/EventModel.java
Modified: xmlgraphics/fop/trunk/src/java/org/apache/fop/events/model/EventModel.java
URL: http://svn.apache.org/viewvc/xmlgraphics/fop/trunk/src/java/org/apache/fop/events/model/EventModel.java?rev=676161&r1=676160&r2=676161&view=diff
==============================================================================
--- xmlgraphics/fop/trunk/src/java/org/apache/fop/events/model/EventModel.java (original)
+++ xmlgraphics/fop/trunk/src/java/org/apache/fop/events/model/EventModel.java Sat Jul 12 05:19:40 2008
@@ -46,15 +46,15 @@
public class EventModel implements Serializable, XMLizable {
private static final long serialVersionUID = 7468592614934605082L;
-
+
private Map producers = new java.util.LinkedHashMap();
-
+
/**
* Creates a new, empty event model
*/
public EventModel() {
}
-
+
/**
* Adds the model of an event producer to the event model.
* @param producer the event producer model
@@ -62,7 +62,7 @@
public void addProducer(EventProducerModel producer) {
this.producers.put(producer.getInterfaceName(), producer);
}
-
+
/**
* Returns an iterator over the contained event producer models.
* @return an iterator (Iterator<EventProducerModel>)
@@ -79,7 +79,7 @@
public EventProducerModel getProducer(String interfaceName) {
return (EventProducerModel)this.producers.get(interfaceName);
}
-
+
/**
* Returns the model of an event producer with the given interface.
* @param clazz the interface of the event producer
@@ -88,7 +88,7 @@
public EventProducerModel getProducer(Class clazz) {
return getProducer(clazz.getName());
}
-
+
/** {@inheritDoc} */
public void toSAX(ContentHandler handler) throws SAXException {
AttributesImpl atts = new AttributesImpl();
@@ -102,8 +102,9 @@
}
private void writeXMLizable(XMLizable object, File outputFile) throws IOException {
- Result res = new StreamResult(outputFile);
-
+ //Result res = new StreamResult(outputFile); //Does not seem to work in all environments
+ Result res = new StreamResult(outputFile.toURI().toURL().toExternalForm());
+
try {
SAXTransformerFactory tFactory
= (SAXTransformerFactory)SAXTransformerFactory.newInstance();
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-commits-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-commits-help@xmlgraphics.apache.org
Re: svn commit: r676161 - /xmlgraphics/fop/trunk/src/java/org/apache/fop/events/model/EventModel.java
Posted by "Peter B. West" <li...@pbw.id.au>.
Jeremias Maerki wrote:
> On 12.07.2008 14:49:03 Andreas Delmelle wrote:
>> On Jul 12, 2008, at 14:19, jeremias@apache.org wrote:
>>
>>> Author: jeremias
>>> Date: Sat Jul 12 05:19:40 2008
>>> New Revision: 676161
>>>
>>> URL: http://svn.apache.org/viewvc?rev=676161&view=rev
>>> Log:
>>> Attempt to fix a potential build problem.
>> FWIW, I've locally replaced all occurrences of File.toURL() in the
>> codebase to File.toURI().toURL(). Once I've confirmed this breaks no
>> tests, I'll commit the changes, so this is out of the way.
>
> Thanks a lot.
>
>> Going through the occurrences, I'm getting the impression that in
>> some cases, we don't even really need the URL. The URI would do just
>> fine if we don't need the functionality for opening a stream... Maybe
>> in this particular case, passing through a URL could also be avoided
>> (?) If the error is generated by the used StreamResult implementation
>> calling File.toURL(), then something like:
>>
>> Result res = new StreamResult(outputFile.toURI().toASCIIString());
>>
>> would already be enough (?)
>
> In most cases, yes. But there's really a difference between a URI and a
> URL. But what's confusing is the following (the Javadocs for
> StreamSource):
>
> <quote>
> public StreamSource(String systemId)
> Construct a StreamSource from a URL.
> Parameters:
> systemId - Must be a String that conforms to the URI syntax.
> </quote>
>
> URL and URI are both used here. But I think "URL" is the mandatory term
> here. The other thing is "URI Syntax" which does not refer to "URI"
> itself. Since a URL is a URI, but not all URIs are URLs, I believe your
> example above is slightly incorrect.
>
> Jeremias Maerki
It's a SystemId. The class includes setSystemId(...) and
setPublicId(...), so a URL looks right. One way to find out.
--
Peter B. West <http://cv.pbw.id.au/>
Folio <http://defoe.sourceforge.net/folio/>
Re: svn commit: r676161 - /xmlgraphics/fop/trunk/src/java/org/apache/fop/events/model/EventModel.java
Posted by Andreas Delmelle <an...@telenet.be>.
On Jul 13, 2008, at 04:07, Peter B. West wrote:
> Andreas Delmelle wrote:
>>>
>>> URL and URI are both used here. But I think "URL" is the
>>> mandatory term
>>> here. The other thing is "URI Syntax" which does not refer to "URI"
>>> itself. Since a URL is a URI, but not all URIs are URLs, I
>>> believe your
>>> example above is slightly incorrect.
>> Nice catch. For the moment, better to be safe than sorry. Indeed,
>> a URI could also be something not referring to a file (or, better
>> put: a valid input source for a transformation)
>> Strictly speaking, according to the above definition, the systemId
>> is allowed to be a 'mailto:' (?) :-/
>> Sloppy editors... ;-)
>
> I don't think so. The docs for java.net.URL include
> "The syntax of URL is defined by RFC 2396: Uniform Resource
> Identifiers (URI): Generic Syntax, amended by RFC 2732: Format for
> Literal IPv6 Addresses in URLs."
>
> That is, the syntax for URLs is defined as part of the URI syntax.
Yes, that's the point, but 'URI Syntax' is more general. All URLs are
URIs, but URIs can also be opaque, like a mailto:, news:, isbn:...
The point is that the API docs of
javax.xml.transform.stream.StreamSource do not explicitly limit the
parameter to URLs. They do indicate that the constructor is meant to
create a new StreamSource off a URL, but it does not even hint at the
(common-sense) requirement that the parameter String actually points
to a valid, live resource that can be an input source for a
transformation.
No immediate problem for us, but it just seems a bit sloppy on the
side of the maintainers of those docs...
Andreas
Re: svn commit: r676161 - /xmlgraphics/fop/trunk/src/java/org/apache/fop/events/model/EventModel.java
Posted by "Peter B. West" <li...@pbw.id.au>.
Andreas Delmelle wrote:
> On Jul 12, 2008, at 14:57, Jeremias Maerki wrote:
>
>> On 12.07.2008 14:49:03 Andreas Delmelle wrote:
>>> Going through the occurrences, I'm getting the impression that in
>>> some cases, we don't even really need the URL. The URI would do just
>>> fine if we don't need the functionality for opening a stream... Maybe
>>> in this particular case, passing through a URL could also be avoided
>>> (?) If the error is generated by the used StreamResult implementation
>>> calling File.toURL(), then something like:
>>>
>>> Result res = new StreamResult(outputFile.toURI().toASCIIString());
>>>
>>> would already be enough (?)
>>
>> In most cases, yes. But there's really a difference between a URI and a
>> URL. But what's confusing is the following (the Javadocs for
>> StreamSource):
>>
>> <quote>
>> public StreamSource(String systemId)
>> Construct a StreamSource from a URL.
>> Parameters:
>> systemId - Must be a String that conforms to the URI syntax.
>> </quote>
>>
>> URL and URI are both used here. But I think "URL" is the mandatory term
>> here. The other thing is "URI Syntax" which does not refer to "URI"
>> itself. Since a URL is a URI, but not all URIs are URLs, I believe your
>> example above is slightly incorrect.
>
> Nice catch. For the moment, better to be safe than sorry. Indeed, a URI
> could also be something not referring to a file (or, better put: a valid
> input source for a transformation)
> Strictly speaking, according to the above definition, the systemId is
> allowed to be a 'mailto:' (?) :-/
>
> Sloppy editors... ;-)
>
I don't think so. The docs for java.net.URL include
"The syntax of URL is defined by RFC 2396: Uniform Resource Identifiers
(URI): Generic Syntax, amended by RFC 2732: Format for Literal IPv6
Addresses in URLs."
That is, the syntax for URLs is defined as part of the URI syntax.
--
Peter B. West <http://cv.pbw.id.au/>
Folio <http://defoe.sourceforge.net/folio/>
Re: svn commit: r676161 - /xmlgraphics/fop/trunk/src/java/org/apache/fop/events/model/EventModel.java
Posted by Andreas Delmelle <an...@telenet.be>.
On Jul 12, 2008, at 14:57, Jeremias Maerki wrote:
> On 12.07.2008 14:49:03 Andreas Delmelle wrote:
>> Going through the occurrences, I'm getting the impression that in
>> some cases, we don't even really need the URL. The URI would do just
>> fine if we don't need the functionality for opening a stream... Maybe
>> in this particular case, passing through a URL could also be avoided
>> (?) If the error is generated by the used StreamResult implementation
>> calling File.toURL(), then something like:
>>
>> Result res = new StreamResult(outputFile.toURI().toASCIIString());
>>
>> would already be enough (?)
>
> In most cases, yes. But there's really a difference between a URI
> and a
> URL. But what's confusing is the following (the Javadocs for
> StreamSource):
>
> <quote>
> public StreamSource(String systemId)
> Construct a StreamSource from a URL.
> Parameters:
> systemId - Must be a String that conforms to the URI syntax.
> </quote>
>
> URL and URI are both used here. But I think "URL" is the mandatory
> term
> here. The other thing is "URI Syntax" which does not refer to "URI"
> itself. Since a URL is a URI, but not all URIs are URLs, I believe
> your
> example above is slightly incorrect.
Nice catch. For the moment, better to be safe than sorry. Indeed, a
URI could also be something not referring to a file (or, better put:
a valid input source for a transformation)
Strictly speaking, according to the above definition, the systemId is
allowed to be a 'mailto:' (?) :-/
Sloppy editors... ;-)
Cheers
Andreas
Re: svn commit: r676161 - /xmlgraphics/fop/trunk/src/java/org/apache/fop/events/model/EventModel.java
Posted by Jeremias Maerki <de...@jeremias-maerki.ch>.
On 12.07.2008 14:49:03 Andreas Delmelle wrote:
> On Jul 12, 2008, at 14:19, jeremias@apache.org wrote:
>
> > Author: jeremias
> > Date: Sat Jul 12 05:19:40 2008
> > New Revision: 676161
> >
> > URL: http://svn.apache.org/viewvc?rev=676161&view=rev
> > Log:
> > Attempt to fix a potential build problem.
>
> FWIW, I've locally replaced all occurrences of File.toURL() in the
> codebase to File.toURI().toURL(). Once I've confirmed this breaks no
> tests, I'll commit the changes, so this is out of the way.
Thanks a lot.
> Going through the occurrences, I'm getting the impression that in
> some cases, we don't even really need the URL. The URI would do just
> fine if we don't need the functionality for opening a stream... Maybe
> in this particular case, passing through a URL could also be avoided
> (?) If the error is generated by the used StreamResult implementation
> calling File.toURL(), then something like:
>
> Result res = new StreamResult(outputFile.toURI().toASCIIString());
>
> would already be enough (?)
In most cases, yes. But there's really a difference between a URI and a
URL. But what's confusing is the following (the Javadocs for
StreamSource):
<quote>
public StreamSource(String systemId)
Construct a StreamSource from a URL.
Parameters:
systemId - Must be a String that conforms to the URI syntax.
</quote>
URL and URI are both used here. But I think "URL" is the mandatory term
here. The other thing is "URI Syntax" which does not refer to "URI"
itself. Since a URL is a URI, but not all URIs are URLs, I believe your
example above is slightly incorrect.
Jeremias Maerki
Re: svn commit: r676161 - /xmlgraphics/fop/trunk/src/java/org/apache/fop/events/model/EventModel.java
Posted by Andreas Delmelle <an...@telenet.be>.
On Jul 12, 2008, at 14:19, jeremias@apache.org wrote:
> Author: jeremias
> Date: Sat Jul 12 05:19:40 2008
> New Revision: 676161
>
> URL: http://svn.apache.org/viewvc?rev=676161&view=rev
> Log:
> Attempt to fix a potential build problem.
FWIW, I've locally replaced all occurrences of File.toURL() in the
codebase to File.toURI().toURL(). Once I've confirmed this breaks no
tests, I'll commit the changes, so this is out of the way.
Going through the occurrences, I'm getting the impression that in
some cases, we don't even really need the URL. The URI would do just
fine if we don't need the functionality for opening a stream... Maybe
in this particular case, passing through a URL could also be avoided
(?) If the error is generated by the used StreamResult implementation
calling File.toURL(), then something like:
Result res = new StreamResult(outputFile.toURI().toASCIIString());
would already be enough (?)
Andreas