xmlgraphics-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeremias Maerki <...@jeremias-maerki.ch>
Subject Re: URIResolvers
Date Mon, 25 Aug 2008 07:23:22 GMT
(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


Mime
View raw message