commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sandy McArthur" <sandy...@gmail.com>
Subject Re: JMimeMagic (was [fileUpload] file content-type)
Date Wed, 19 Apr 2006 17:39:29 GMT
On 4/19/06, Jörg Schaible <joerg.schaible@gmx.de> wrote:
> Sandy McArthur wrote:
>
> > This project would also benefit from providing metadata to the  Java
> > Activation Framework. http://java.sun.com/products/javabeans/jaf/
> >
> > On 4/19/06, Markus Härnvi <markus@harnvi.net> wrote:
> >> Jörg Schaible wrote:
> >> > That would have been my approach also. I was just not sure, whether we
> >> > should bundle the magic file or try to locate it (this is the
> >> > interesting part and highly system dependent). And a user might have an
> >> > additional magic file in its home - at least this can be located.
> >>
> >> I would wote for bundle, but maybe with an option to search for it.
> >> Windows users don't have it at all, I guess.
> >
> > I'm of the mind that a file type matcher interface should be declared
> > and various implementations should be provided by factories discovered
> > by the Java Service Provider framework [1].  This would allow a basic
> > implementation that creates matchers from an existing unix-like magic
> > file and more complete implementations can be dropped in later by
> > simply adding them to the classpath.
>
> So we're back to the Service Provider discussion, since [1] only refers a
> specification, but no implementation :)
>
> What was the consensus regarding this in lang? IIRC basically yes, but
> no-one did provide it :)
>
> > The hard part is what that matcher interface expects the data to be
> > in. I can imagine programmers wanting to discover what byte arrays,
> > InputStreams, Readers, Strings, ByteBuffer, and Files contain.
> >
> > Personally, I think Streams and Reader should be dropped as they
> > aren't designed for seek ability and you have to jump through hoops to
> > keep the bytes you read to discover the file type available elsewhere.
> > I like the java.nio.ByteBuffer as the format pass data into the
> > matcher as it's rather easy to get data into it and it can be
> > optimized for File sources.
>
> ByteBuffer is 1.4, but probably it is time to move on at least for new
> components.
>
> >
> > 1.
> > http://java.sun.com/j2se/1.4.2/docs/guide/jar/jar.html#Service%20Provider

FWIW: Java 1.4 does provied a ServiceProvier look up tool hidden away
in the javax.imageio.spi package. ServiceRegistry has some static
lookupProviders methods that do just that:
http://tinyurl.com/rnz2s or
http://java.sun.com/j2se/1.4.2/docs/api/javax/imageio/spi/ServiceRegistry.html#lookupProviders(java.lang.Class,%20java.lang.ClassLoader)

--
Sandy McArthur

"He who dares not offend cannot be honest."
- Thomas Paine

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org


Mime
View raw message