You are viewing a plain text version of this content. The canonical link for it is here.
Posted to batik-dev@xmlgraphics.apache.org by Thomas E Deweese <th...@kodak.com> on 2001/04/26 14:39:26 UTC
Automagic Image Tag Handling Support
Hi all,
I didn't get any responses from my query about the "standard" way
to do automatic addition of Service Provider Interfaces. So let me
tell people what I have done, and lets see what people thing :).
When the ImageTagRegistry is first requested it calls
'getResources("META-INF/MANIFEST.MF")' on it's ClassLoader this
returns all of the manifest files for all the JARS on the class path.
It then looks for the 'Batik-RegistryEntry' attribute in the
Manifests "Main Attributes" (I'm not sure if we could create our own
section - or exactly how one does that :).
This attribute should be a white space separated list of fully
qualified class names that implement the RegistryEntry interface. It
then tries constructing an instance of each and if that succeeds it
registers them with the ImageTagRegistry.
I have tested this, and it means support for new formats can be
added simply by putting a new jar file on the class path.
PRETTY COOL!
--
Other places where this sort of things should probably also be done
in Batik:
1) Protocol Handlers for the ParsedURL.
2) The 'Bridge' classes that go into the Bridge Context (support
for tag types based simply on adding jars to the class path).
What do people think?
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-dev-help@xml.apache.org
Re: Automagic Image Tag Handling Support
Posted by Thomas E Deweese <th...@kodak.com>.
>>>>> "CJ" == Christophe Jolif <cj...@ilog.fr> writes:
CJ> In fact it is a non standard class:
CJ> sun.misc.Service
CJ> So we will probably not use it, however it doesn't prevent us from
CJ> using the services directory.
CJ> My vote is +1 on services directory under META-INF.
Good, because last Friday I implemented this and checked it in. :)
This is now how the ImageTagRegistry is extended. I thought I had
made it clear that once you pointed out the official services
extension mechanism I was going to implement it.
There is now a batik.util.Service class that implements the
'providers' method pretty much as described in the document. It also
caches the results of requesting providers to avoid reparsing the
files if the same providers are requested multiple times.
Check it out and get back to me if you have any questions.
I'm now considering how something similar might be done for the
BridgeContext.
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-dev-help@xml.apache.org
Re: Automagic Image Tag Handling Support
Posted by Christophe Jolif <cj...@ilog.fr>.
In fact it is a non standard class:
sun.misc.Service
So we will probably not use it, however it doesn't prevent us from using
the services directory.
My vote is +1 on services directory under META-INF.
Calvin Yu wrote:
>
> --- Thomas E Deweese <th...@kodak.com> wrote:
>
> > Interesting, the Service class they reference in
> > the document
> > doesn't exist!?!?!?!?
>
> I think they're not talking about a specific Service
> class, but describing what services and service
> providers generally are.
>
> Calvin
>
> __________________________________________________
> Do You Yahoo!?
> Yahoo! Auctions - buy the things you want at great prices
> http://auctions.yahoo.com/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: batik-dev-unsubscribe@xml.apache.org
> For additional commands, e-mail: batik-dev-help@xml.apache.org
--
Christophe
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-dev-help@xml.apache.org
Re: Automagic Image Tag Handling Support
Posted by Calvin Yu <cy...@yahoo.com>.
--- Thomas E Deweese <th...@kodak.com> wrote:
> Interesting, the Service class they reference in
> the document
> doesn't exist!?!?!?!?
I think they're not talking about a specific Service
class, but describing what services and service
providers generally are.
Calvin
__________________________________________________
Do You Yahoo!?
Yahoo! Auctions - buy the things you want at great prices
http://auctions.yahoo.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-dev-help@xml.apache.org
Re: Automagic Image Tag Handling Support
Posted by Thomas E Deweese <th...@kodak.com>.
>>>>> "CJ" == Christophe Jolif <cj...@ilog.fr> writes:
CJ> Thomas, I'm not a jar expert but looking at:
CJ> http://java.sun.com/j2se/1.3/docs/guide/jar/jar.html#JAR Manifest
CJ> It looks like there is a "standard" way for listing services class
CJ> in a jar file (services directory under META-INF). Is there a
CJ> strong reason for not using it?
Only my previous inability to locate the standard way.
I had spent a nontrivial amount of time searching the Javasoft web
site and couldn't find this. I'm in the processes of bringing our
implementation into line with this.
Interesting, the Service class they reference in the document
doesn't exist!?!?!?!?
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-dev-help@xml.apache.org
Re: Automagic Image Tag Handling Support
Posted by Christophe Jolif <cj...@ilog.fr>.
Thomas,
I'm not a jar expert but looking at:
http://java.sun.com/j2se/1.3/docs/guide/jar/jar.html#JAR Manifest
It looks like there is a "standard" way for listing services class in a
jar file (services directory under META-INF). Is there a strong reason
for not using it?
Thomas E Deweese wrote:
>
> Hi all,
>
> I didn't get any responses from my query about the "standard" way
> to do automatic addition of Service Provider Interfaces. So let me
> tell people what I have done, and lets see what people thing :).
>
> When the ImageTagRegistry is first requested it calls
> 'getResources("META-INF/MANIFEST.MF")' on it's ClassLoader this
> returns all of the manifest files for all the JARS on the class path.
>
> It then looks for the 'Batik-RegistryEntry' attribute in the
> Manifests "Main Attributes" (I'm not sure if we could create our own
> section - or exactly how one does that :).
>
> This attribute should be a white space separated list of fully
> qualified class names that implement the RegistryEntry interface. It
> then tries constructing an instance of each and if that succeeds it
> registers them with the ImageTagRegistry.
>
> I have tested this, and it means support for new formats can be
> added simply by putting a new jar file on the class path.
>
> PRETTY COOL!
>
> --
>
> Other places where this sort of things should probably also be done
> in Batik:
>
> 1) Protocol Handlers for the ParsedURL.
>
> 2) The 'Bridge' classes that go into the Bridge Context (support
> for tag types based simply on adding jars to the class path).
>
> What do people think?
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: batik-dev-unsubscribe@xml.apache.org
> For additional commands, e-mail: batik-dev-help@xml.apache.org
--
Christophe
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-dev-help@xml.apache.org
Re: Automagic Image Tag Handling Support
Posted by Vincent Hardy <vh...@eng.sun.com>.
Thomas,
Thomas E Deweese wrote:
>
>
> I have tested this, and it means support for new formats can be
> added simply by putting a new jar file on the class path.
>
> PRETTY COOL!
>
Yes indeed! I think this is also consistent with the upcoming Image
I/0 approach for additional image formats.
> --
>
> Other places where this sort of things should probably also be done
> in Batik:
>
> 1) Protocol Handlers for the ParsedURL.
>
> 2) The 'Bridge' classes that go into the Bridge Context (support
> for tag types based simply on adding jars to the class path).
>
> What do people think?
I like the idea for supporting additional tags. Btw, this is something
we should demonstrate and document for 1.0.
V.
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-dev-help@xml.apache.org
Re: Automagic Image Tag Handling Support
Posted by Steve Loughran <st...@iseran.com>.
----- Original Message -----
From: "Thomas E Deweese" <th...@kodak.com>
To: <ba...@xml.apache.org>
Sent: Friday, April 27, 2001 07:37
Subject: Re: Automagic Image Tag Handling Support
> The only real objection I have to this is that most build
> environments don't support this. I know Batik's doesn't, and our in
> house Java environment doesn't, where as virtually all java
> development environments will support providing manifest files.
>
> So anyone who has an opinion between the two options:
>
> 1) Leave tag in the Manifest.
> 2) Move to org.apache.batik in META-INF
>
> Please vote, and I'll probably do what the majority decides.
+1 on a file in the services subdir; it would make merging requirements
clearer.
As far as build processes goes, it should be fairly easy in ant using jar or
jlink. If ant jar doesnt do it, then it can be added in .
-Steve
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-dev-help@xml.apache.org
Re: Automagic Image Tag Handling Support
Posted by Thomas E Deweese <th...@kodak.com>.
>>>>> "CY" == Calvin Yu <cy...@yahoo.com> writes:
CY> I've seen some libraries that put these types of files under the
CY> META-INF directory, but in its own file (JavaMail). I'm not sure
CY> the manifest is really meant for these kinds of tasks, but I'm no
CY> jar expert.
Well, putting it in a separate file in the META-INF directly has
some merit. Currently, it ends up looking at _every_ manifest file
in the class path even though most don't have anything in them. By
putting it in a separate file the 'hit rate' would go way up (much
less wasted work parsing manifest files). It would also allow us to
name the file 'org.apache.batik' which should prevent any possible
name collisions.
The only real objection I have to this is that most build
environments don't support this. I know Batik's doesn't, and our in
house Java environment doesn't, where as virtually all java
development environments will support providing manifest files.
So anyone who has an opinion between the two options:
1) Leave tag in the Manifest.
2) Move to org.apache.batik in META-INF
Please vote, and I'll probably do what the majority decides.
If it stays in the Manifest I'm going to write a util class that
all the dynamic extensions can use that will parse the manifests once
and only once (when first requested).
CY> I've also seen some libraries put the properties file in the same
CY> directory as the class loading it and using
CY> Class.getResourceAsStream() (I think Ant does this).
I don't like this since it would mean that people who wanted to
add new codecs would have to add 'batik' directories to there jar
files so they could put the 'manifest' file in the right place.
CY> One problem with putting that property in the manifest is that if
CY> someone decides to merge batik into their own jar it might not be
CY> apparent that they'll need to merge the manifest files.
Currently Batik 'hard codes' the built in file types (it doesn't
use it's own extension mechanism to register them). So this isn't
currently a huge issue. But if someone were building a monolithic JAR
file including several extensions (not an unreasonable thing to do)
they would need to be very careful, but that is, to a certain extent,
an issue for all of the above cases (if you have more than one
'org.apache.batik' file you need to merge them - no way around it).
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-dev-help@xml.apache.org
Re: Automagic Image Tag Handling Support
Posted by Calvin Yu <cy...@yahoo.com>.
I've seen some libraries that put these types of files
under the META-INF directory, but in its own file
(JavaMail). I'm not sure the manifest is really meant
for these kinds of tasks, but I'm no jar expert. I've
also seen some libraries put the properties file in
the same directory as the class loading it and using
Class.getResourceAsStream() (I think Ant does this).
One problem with putting that property in the manifest
is that if someone decides to merge batik into their
own jar it might not be apparent that they'll need to
merge the manifest files.
Calvin
--- Thomas E Deweese <th...@kodak.com> wrote:
>
> Hi all,
>
> I didn't get any responses from my query about
> the "standard" way
> to do automatic addition of Service Provider
> Interfaces. So let me
> tell people what I have done, and lets see what
> people thing :).
>
>
> When the ImageTagRegistry is first requested it
> calls
> 'getResources("META-INF/MANIFEST.MF")' on it's
> ClassLoader this
> returns all of the manifest files for all the JARS
> on the class path.
>
> It then looks for the 'Batik-RegistryEntry'
> attribute in the
> Manifests "Main Attributes" (I'm not sure if we
> could create our own
> section - or exactly how one does that :).
>
> This attribute should be a white space separated
> list of fully
> qualified class names that implement the
> RegistryEntry interface. It
> then tries constructing an instance of each and if
> that succeeds it
> registers them with the ImageTagRegistry.
>
> I have tested this, and it means support for new
> formats can be
> added simply by putting a new jar file on the class
> path.
>
> PRETTY COOL!
>
> --
>
> Other places where this sort of things should
> probably also be done
> in Batik:
>
> 1) Protocol Handlers for the ParsedURL.
>
> 2) The 'Bridge' classes that go into the Bridge
> Context (support
> for tag types based simply on adding jars to
> the class path).
>
> What do people think?
>
>
---------------------------------------------------------------------
> To unsubscribe, e-mail:
> batik-dev-unsubscribe@xml.apache.org
> For additional commands, e-mail:
> batik-dev-help@xml.apache.org
>
__________________________________________________
Do You Yahoo!?
Yahoo! Auctions - buy the things you want at great prices
http://auctions.yahoo.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-dev-help@xml.apache.org