You are viewing a plain text version of this content. The canonical link for it is here.
Posted to general@xmlgraphics.apache.org by Jeremias Maerki <de...@jeremias-maerki.ch> on 2008/08/25 09:23:22 UTC
Re: URIResolvers
(Moving to general as we're talking about code in Commons, not FOP)
Thanks for sharing. I have two observations here:
1. CommonURIResolver is final and designed as a Singleton. In my past
experience that restricts its usefulness too much. If you look at all
the "registries" in FOP you'll see that they are not singletons but
attached to the FopFactory (which isn't a singleton either). That allows
to have multiple "environments" inside the same JVM/classloader setup if
someone desires that. If someone wants a singleton for a particular
purpose he can always do so easily. But if it's already a singleton you
are locked in. Anyway, I've made it a habit of avoiding singletons
whenever possible.
2. It should be noted that this approach here only allows "general"
resolvers. There's no access to "local" configuration or context
information that allows customizing the behaviour. Such URI resolver
will still have to be set up by the users.
I'm curious: what kind of URI resolver do you want to add here from a
plug-in that motivated you to do this?
On 25.08.2008 08:47:39 Max Berger wrote:
> Jeremias,
>
> my fault again. You are absolutely right, I should provide a
> "deprecated" version of the old classes in all cases, and probably
> discuss the idea.
>
> I'll do the later today, and here's the second one:
>
> Background is this thread [1] which showed a flaw in the way FOP
> resolves URIs.
>
> Current Situation:
> * FOP provides support for 1 Custom Resolver
> * It also adds the data: URI resolver
> * and has a sophisticated resolving method for other URIs which are
> openable through URL.open (better than the JDK default)
>
> Problem:
> A plugin cannot add a URIResolver to FOP, as there is only 1 custom
> resolver, and it is defined by the user.
>
> Main Idea:
> Support a generic "chain" of URIResolvers. All URI resolvers are called
> in order, if one of them can resolve the URI it will return a source,
> otherwise null.
>
> Implementation Idea:
> Need a URIResolver registry, like the ImageLoader registry. It should
> automatically load all URIResolvers declared as service, and provide
> register() and unregister() functionality.
>
> A Generic URI resolver will then try all registered resolvers first, and
> then fall back to the default (which would be the functionality as it is
> in FOP now).
>
> Plugins can then register their own URI resolver, which could either add
> URIs (there are some examples of a XML: URI in commons, which would be
> interesting), or provide mapping for well-known URIs, such as the ones
> of DTDs and entities.
>
> [1]
> http://www.nabble.com/Getting-Batik-to-read-SVG-DTDs-via-catalog-resolver-td18169780.html
>
> Hope this makes sense
>
> Max
>
> Jeremias Maerki schrieb:
> > I'm seeing a new pattern here and I'm not entirely happy about it. I'd
> > prefer at least a short deprecation time (one release) before final
> > removal. Also a short discussion or at least an advance notice about
> > someone's intentions and motivations would be appreciated. But maybe
> > that's only me.
> >
> > On 24.08.2008 15:12:02 maxberger wrote:
> >> Author: maxberger
> >> Date: Sun Aug 24 06:12:02 2008
> >> New Revision: 688508
> >>
> >> URL: http://svn.apache.org/viewvc?rev=688508&view=rev
> >> Log:
> >> Moved DataURIResolver from FOP to commons; use new URIResolver registry
> >>
> >> Removed:
> >> xmlgraphics/fop/trunk/src/java/org/apache/fop/util/DataURIResolver.java
> >> xmlgraphics/fop/trunk/src/java/org/apache/fop/util/DataURLUtil.java
> >> xmlgraphics/fop/trunk/src/java/org/apache/fop/util/WriterOutputStream.java
> >> xmlgraphics/fop/trunk/test/java/org/apache/fop/util/DataURIResolverTestCase.java
> >> Modified:
> >> xmlgraphics/fop/trunk/lib/xmlgraphics-commons-1.4svn.jar
> >> xmlgraphics/fop/trunk/src/java/org/apache/fop/apps/FOURIResolver.java
> >> xmlgraphics/fop/trunk/test/java/org/apache/fop/UtilityCodeTestSuite.java
> >
> >
> > On 20.08.2008 17:13:56 acumiskey wrote:
> >> Author: acumiskey
> >> Date: Wed Aug 20 08:13:56 2008
> >> New Revision: 687369
> >>
> >> URL: http://svn.apache.org/viewvc?rev=687369&view=rev
> >> Log:
> >> * Updated xmlgraphics-commons-14svn.jar to reflect UnitConv additions.
> >> * Removed UnitConv and its unit test case (now resides in commons).
> >> * Updated all fop util package references fpr UnitConv to xmlgraphics commons util package.
> >>
> >> Removed:
> >> xmlgraphics/fop/trunk/src/java/org/apache/fop/util/UnitConv.java
> >> xmlgraphics/fop/trunk/test/java/org/apache/fop/util/UnitConvTestCase.java
> >> Modified:
> >> xmlgraphics/fop/trunk/lib/xmlgraphics-commons-1.4svn.jar
> >> xmlgraphics/fop/trunk/src/java/org/apache/fop/render/AbstractGraphics2DAdapter.java
> >> xmlgraphics/fop/trunk/src/java/org/apache/fop/render/AbstractPathOrientedRenderer.java
> >> xmlgraphics/fop/trunk/src/java/org/apache/fop/render/pcl/PCLGenerator.java
> >> xmlgraphics/fop/trunk/src/java/org/apache/fop/render/pcl/PCLGraphics2D.java
> >> xmlgraphics/fop/trunk/src/java/org/apache/fop/render/pcl/PCLGraphics2DAdapter.java
> >> xmlgraphics/fop/trunk/src/java/org/apache/fop/render/pcl/PCLPageDefinition.java
> >> xmlgraphics/fop/trunk/src/java/org/apache/fop/render/pcl/PCLRenderer.java
> >> xmlgraphics/fop/trunk/src/java/org/apache/fop/render/txt/TXTRenderer.java
> >> xmlgraphics/fop/trunk/test/java/org/apache/fop/UtilityCodeTestSuite.java
> >
> >
> >
> > Jeremias Maerki
> >
>
>
Jeremias Maerki
---------------------------------------------------------------------
Apache XML Graphics Project URL: http://xmlgraphics.apache.org/
To unsubscribe, e-mail: general-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: general-help@xmlgraphics.apache.org
Re: URIResolvers
Posted by Jeremias Maerki <de...@jeremias-maerki.ch>.
On 25.08.2008 10:33:37 Max Berger wrote:
> Jeremias,
>
> Jeremias Maerki schrieb:
> > (Moving to general as we're talking about code in Commons, not FOP)
> >
> > Thanks for sharing. I have two observations here:
> > 1. CommonURIResolver is final and designed as a Singleton. In my past
> > experience that restricts its usefulness too much.
>
> Noted. I'll make it public and rename the getInstance to getDefault...
Thanks.
> > 2. It should be noted that this approach here only allows "general"
> > resolvers. There's no access to "local" configuration or context
> > information that allows customizing the behaviour. Such URI resolver
> > will still have to be set up by the users.
>
> The URIResolver in FOP will probably have to stay very similar to the
> way it works right now, for that exact reason.
I don't mean to imply that anything should be changed now. I'm just
noting the consequence of the design decision.
> > I'm curious: what kind of URI resolver do you want to add here from a
> > plug-in that motivated you to do this?
>
> One that resolves well-known URIs to embedded URIs. In particular URIs
> such as
> "http://www.w3.org/Math/DTD/mathml2/mathml2.dtd" and
> "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd" would be mapped to
> jar:... for faster (and in particular offline) resolution.
>
> For testing purposes, the xml: URI seems like a very interesting addition.
Ah, makes sense. Thanks. And the W3C web admins will be very happy about
this. ;-)
>
> Max
>
>
Jeremias Maerki
---------------------------------------------------------------------
Apache XML Graphics Project URL: http://xmlgraphics.apache.org/
To unsubscribe, e-mail: general-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: general-help@xmlgraphics.apache.org
Re: URIResolvers
Posted by Max Berger <ma...@berger.name>.
Jeremias,
Jeremias Maerki schrieb:
> (Moving to general as we're talking about code in Commons, not FOP)
>
> Thanks for sharing. I have two observations here:
> 1. CommonURIResolver is final and designed as a Singleton. In my past
> experience that restricts its usefulness too much.
Noted. I'll make it public and rename the getInstance to getDefault...
> 2. It should be noted that this approach here only allows "general"
> resolvers. There's no access to "local" configuration or context
> information that allows customizing the behaviour. Such URI resolver
> will still have to be set up by the users.
The URIResolver in FOP will probably have to stay very similar to the
way it works right now, for that exact reason.
> I'm curious: what kind of URI resolver do you want to add here from a
> plug-in that motivated you to do this?
One that resolves well-known URIs to embedded URIs. In particular URIs
such as
"http://www.w3.org/Math/DTD/mathml2/mathml2.dtd" and
"http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd" would be mapped to
jar:... for faster (and in particular offline) resolution.
For testing purposes, the xml: URI seems like a very interesting addition.
Max