You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Stephen McConnell <mc...@apache.org> on 2003/11/12 14:21:21 UTC
[repository] mime type addition?
Have started some experimentation with content negotiation
and I think I need a mime type addition to server running
www.apache.org.
I have setup the following test content:
http://www.apache.org/~mcconnell/
This contains a single jar file and a test file containing
metadata about the jar file.
example.jar
example.jar.meta
I've also put together a little test case that creates a url
to the artifact http://www.apache.org/~mcconnell/example
and then sets the "accept" request parameter to "text/x-meta".
Presumably the mime type used here ("text/x-meta") needs to be
declared on the Apache server with a mapping to the ".meta"
extension.
Does anyone know if this is something I can configure
in the enclosing directory - or do I need post a request to
infrastructure?
Here is a fragment of the relevant java source:
URL url = new URL( "http://www.apache.org/~mcconnell/test/example" );
URLConnection connection = url.openConnection();
connection.setRequestProperty( "accept", "text/x-meta" );
getLogger().info( "input" );
InputStream input = (InputStream) connection.getContent();
Properties properties = new Properties();
properties.load( input );
Without the mime mapping the above code will result in the stuffing
of the jar file into the properties file which is not exactly
what we want.
Cheers, Steve.
--
Stephen J. McConnell
mailto:mcconnell@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [repository] mime type addition?
Posted by Stephen McConnell <mc...@apache.org>.
Alex Karasulu wrote:
>Steve,
>
>If I ask for meta content then would the file the server tried to return
>back to me be example.meta rather than example.jar.meta?
>
I think so. For example - I could put in place a resource named
*example.jar.meta.fr* - and what I should get back is a french version
of the meta description if my client content request was configure for
the french langauge as a priority.
Stephen.
--
Stephen J. McConnell
mailto:mcconnell@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
RE: [repository] mime type addition?
Posted by Alex Karasulu <ao...@bellsouth.net>.
Steve,
If I ask for meta content then would the file the server tried to return
back to me be example.meta rather than example.jar.meta?
Alex
> -----Original Message-----
> From: Stephen McConnell [mailto:mcconnell@apache.org]
> Sent: Thursday, November 13, 2003 9:59 AM
> To: Avalon Developers List
> Subject: Re: [repository] mime type addition?
>
>
>
> Alex Karasulu wrote:
>
> >Ok I'm a little dense so bear with me. I see the webserver now
> recognizes
> >and sets the mime type based on the .meta file extension. Why is this so
> >significant to us?
> >
>
> It means that the client application (i.e. the repository implementation
> classes) can take advantate of the x-meta mime type. Based on the user
> supply of a group and artifact we can make a request for the meta data
> without resorting to a url that exposes anything more than the fgroup
> and artifact.
>
> Specifically:
>
> http://www.apache.org/~mcconnell/test/example
>
> This url is sufficient for the retrival of the jar (a mime type) and the
> meta about the jar (another mime type). Instead of building an explict
> url to a <something>.meta - we can use HTTP content rules to get what we
> want (jar versus meta data about the jar). This means that the question
> of how meta data is associated with an artifact is no longer a client
> concern - its a server implementation concern.
>
> >
> >Your example is also very confusing to me as well. Can you explain it?
> Why
> >would trying to get http://www.apache.org/~mcconnell/test/example work.
> You
> >only have the following in this directory:
> >
> >example.jar
> >example.jar.meta
> >
>
> Yep.
>
> The artifact url is http://www.apache.org/~mcconnell/test/example
>
> Relative to that artifact there are a number of resources that are
> potentially resolvable - example.jar and example.jar.meta. According o
> the HTTP protocol spec we can set an "Accept" request property to guide
> the server in terms of content negotiation. I.e. the group/artifact is
> sufficent with respect to url - the rest can be resolved using content
> negotiation support.
>
> http://httpd.apache.org/docs-2.0/content-negotiation.html
>
> Steve.
>
> (who is figuring this stuff out as he goes along).
>
> --
>
> Stephen J. McConnell
> mailto:mcconnell@apache.org
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
> For additional commands, e-mail: dev-help@avalon.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [repository] mime type addition?
Posted by Stephen McConnell <mc...@apache.org>.
Eric Pugh wrote:
>I guess one reason though to explicitly load up example.jar and
>example.jar.meta is that when I want to setup my own local repository it's
>easy, all I need to do is have a working webserver. additionally, if I want
>my repository to be just a file system, then it is the same...
>
>One of the nice things about the maven repository was that setting up our
>own corporate one was dirt simple, and runs nicely on IIS. As soon as you
>need to configure meta mimetype you are going to have sysadmins telling you
>"No!"...
>
But that's ok. The client make make assumptions about a document named
xxxx.jar.meta - but if the client ties to get this using a mime type
first - then the server can resolve this using a dozen different
mecanisms. That's the important point - we can transfer the
implementation decision to the server and still maintain a fallback
strategy on the client that is consitent with your local filesystem model.
Cheers, Steve.
>
>Just something to keep in mind, and I'm looking forward to playing with your
>example..
>
>Eric
>
>
>
>>-----Original Message-----
>>From: Stephen McConnell [mailto:mcconnell@apache.org]
>>Sent: Thursday, November 13, 2003 3:59 PM
>>To: Avalon Developers List
>>Subject: Re: [repository] mime type addition?
>>
>>
>>
>>
>>Alex Karasulu wrote:
>>
>>
>>
>>>Ok I'm a little dense so bear with me. I see the webserver
>>>
>>>
>>now recognizes
>>
>>
>>>and sets the mime type based on the .meta file extension.
>>>
>>>
>>Why is this so
>>
>>
>>>significant to us?
>>>
>>>
>>>
>>It means that the client application (i.e. the repository
>>implementation
>>classes) can take advantate of the x-meta mime type. Based
>>on the user
>>supply of a group and artifact we can make a request for the
>>meta data
>>without resorting to a url that exposes anything more than the fgroup
>>and artifact.
>>
>>Specifically:
>>
>> http://www.apache.org/~mcconnell/test/example
>>
>>This url is sufficient for the retrival of the jar (a mime
>>type) and the
>>meta about the jar (another mime type). Instead of building
>>an explict
>>url to a <something>.meta - we can use HTTP content rules to
>>get what we
>>want (jar versus meta data about the jar). This means that
>>the question
>>of how meta data is associated with an artifact is no longer a client
>>concern - its a server implementation concern.
>>
>>
>>
>>>Your example is also very confusing to me as well. Can you
>>>
>>>
>>explain it? Why
>>
>>
>>>would trying to get
>>>
>>>
>http://www.apache.org/~mcconnell/test/example work. You
>
>
>>only have the following in this directory:
>>
>>example.jar
>>example.jar.meta
>>
>>
>>
>
>Yep.
>
>The artifact url is http://www.apache.org/~mcconnell/test/example
>
>Relative to that artifact there are a number of resources that are
>potentially resolvable - example.jar and example.jar.meta. According o
>the HTTP protocol spec we can set an "Accept" request property to guide
>the server in terms of content negotiation. I.e. the group/artifact is
>sufficent with respect to url - the rest can be resolved using content
>negotiation support.
>
>http://httpd.apache.org/docs-2.0/content-negotiation.html
>
>Steve.
>
>(who is figuring this stuff out as he goes along).
>
>--
>
>Stephen J. McConnell
>mailto:mcconnell@apache.org
>
>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
>For additional commands, e-mail: dev-help@avalon.apache.org
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
>For additional commands, e-mail: dev-help@avalon.apache.org
>
>
>
>
--
Stephen J. McConnell
mailto:mcconnell@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
RE: [repository] mime type addition?
Posted by Eric Pugh <ep...@upstate.com>.
I guess one reason though to explicitly load up example.jar and
example.jar.meta is that when I want to setup my own local repository it's
easy, all I need to do is have a working webserver. additionally, if I want
my repository to be just a file system, then it is the same...
One of the nice things about the maven repository was that setting up our
own corporate one was dirt simple, and runs nicely on IIS. As soon as you
need to configure meta mimetype you are going to have sysadmins telling you
"No!"...
Just something to keep in mind, and I'm looking forward to playing with your
example..
Eric
> -----Original Message-----
> From: Stephen McConnell [mailto:mcconnell@apache.org]
> Sent: Thursday, November 13, 2003 3:59 PM
> To: Avalon Developers List
> Subject: Re: [repository] mime type addition?
>
>
>
>
> Alex Karasulu wrote:
>
> >Ok I'm a little dense so bear with me. I see the webserver
> now recognizes
> >and sets the mime type based on the .meta file extension.
> Why is this so
> >significant to us?
> >
>
> It means that the client application (i.e. the repository
> implementation
> classes) can take advantate of the x-meta mime type. Based
> on the user
> supply of a group and artifact we can make a request for the
> meta data
> without resorting to a url that exposes anything more than the fgroup
> and artifact.
>
> Specifically:
>
> http://www.apache.org/~mcconnell/test/example
>
> This url is sufficient for the retrival of the jar (a mime
> type) and the
> meta about the jar (another mime type). Instead of building
> an explict
> url to a <something>.meta - we can use HTTP content rules to
> get what we
> want (jar versus meta data about the jar). This means that
> the question
> of how meta data is associated with an artifact is no longer a client
> concern - its a server implementation concern.
>
> >
> >Your example is also very confusing to me as well. Can you
> explain it? Why
> >would trying to get
http://www.apache.org/~mcconnell/test/example work. You
>only have the following in this directory:
>
>example.jar
>example.jar.meta
>
Yep.
The artifact url is http://www.apache.org/~mcconnell/test/example
Relative to that artifact there are a number of resources that are
potentially resolvable - example.jar and example.jar.meta. According o
the HTTP protocol spec we can set an "Accept" request property to guide
the server in terms of content negotiation. I.e. the group/artifact is
sufficent with respect to url - the rest can be resolved using content
negotiation support.
http://httpd.apache.org/docs-2.0/content-negotiation.html
Steve.
(who is figuring this stuff out as he goes along).
--
Stephen J. McConnell
mailto:mcconnell@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [repository] mime type addition?
Posted by Stephen McConnell <mc...@apache.org>.
Alex Karasulu wrote:
>Ok I'm a little dense so bear with me. I see the webserver now recognizes
>and sets the mime type based on the .meta file extension. Why is this so
>significant to us?
>
It means that the client application (i.e. the repository implementation
classes) can take advantate of the x-meta mime type. Based on the user
supply of a group and artifact we can make a request for the meta data
without resorting to a url that exposes anything more than the fgroup
and artifact.
Specifically:
http://www.apache.org/~mcconnell/test/example
This url is sufficient for the retrival of the jar (a mime type) and the
meta about the jar (another mime type). Instead of building an explict
url to a <something>.meta - we can use HTTP content rules to get what we
want (jar versus meta data about the jar). This means that the question
of how meta data is associated with an artifact is no longer a client
concern - its a server implementation concern.
>
>Your example is also very confusing to me as well. Can you explain it? Why
>would trying to get http://www.apache.org/~mcconnell/test/example work. You
>only have the following in this directory:
>
>example.jar
>example.jar.meta
>
Yep.
The artifact url is http://www.apache.org/~mcconnell/test/example
Relative to that artifact there are a number of resources that are
potentially resolvable - example.jar and example.jar.meta. According o
the HTTP protocol spec we can set an "Accept" request property to guide
the server in terms of content negotiation. I.e. the group/artifact is
sufficent with respect to url - the rest can be resolved using content
negotiation support.
http://httpd.apache.org/docs-2.0/content-negotiation.html
Steve.
(who is figuring this stuff out as he goes along).
--
Stephen J. McConnell
mailto:mcconnell@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
RE: [repository] mime type addition?
Posted by Alex Karasulu <ao...@bellsouth.net>.
Ok I'm a little dense so bear with me. I see the webserver now recognizes
and sets the mime type based on the .meta file extension. Why is this so
significant to us?
Your example is also very confusing to me as well. Can you explain it? Why
would trying to get http://www.apache.org/~mcconnell/test/example work. You
only have the following in this directory:
example.jar
example.jar.meta
Alex
> Based on some help from Erik Abele on infrastructure I was able to
> sort this one out. Erik put together a test case in C to validate
> that the Apache server was doing its thing with respect to content
> negotiation - which left me with the problem of resolving the issues
> with the Java approach.
>
> Detailed below are the issues and solutions.
>
>
> Stephen McConnell wrote:
>
> >
> > Have started some experimentation with content negotiation
> > and I think I need a mime type addition to server running
> > www.apache.org.
> >
> > I have setup the following test content:
> >
> > http://www.apache.org/~mcconnell/
> >
> > This contains a single jar file and a test file containing
> > metadata about the jar file.
> >
> > example.jar
> > example.jar.meta
> >
> > I've also put together a little test case that creates a url
> > to the artifact http://www.apache.org/~mcconnell/example
> > and then sets the "accept" request parameter to "text/x-meta".
> > Presumably the mime type used here ("text/x-meta") needs to be
> > declared on the Apache server with a mapping to the ".meta"
> > extension.
> >
> > Does anyone know if this is something I can configure
> > in the enclosing directory - or do I need post a request to
> > infrastructure?
>
>
> You can declare MIME type additions by putting in place a .htaccess file
> somewhere in the filesystem. For the above example I declared a
> "text/x-meta" MIME type using a .htaccess file containing the following:
>
> AddType text/x-meta .meta
>
> >
> > Here is a fragment of the relevant java source:
> >
> > URL url = new URL( "http://www.apache.org/~mcconnell/test/example" );
> > URLConnection connection = url.openConnection();
> > connection.setRequestProperty( "accept", "text/x-meta" );
>
>
> The above line contains a bug.
> To operate corectly the request property key should be "Accept" (note
> that the value is case sensitive).
>
> >
> > getLogger().info( "input" );
> > InputStream input = (InputStream) connection.getContent();
> > Properties properties = new Properties();
> > properties.load( input );
> >
> > Without the mime mapping the above code will result in the stuffing
> > of the jar file into the properties file which is not exactly
> > what we want.
>
>
> Using the following URL:
>
> http://www.apache.org/~mcconnell/test/example
>
> I can pull down the meta info using the attached testcase resulting in:
>
> [INFO ] (playground.demo): name: avalon-activation-impl
> [INFO ] (playground.demo): group: avalon-activation
> [INFO ] (playground.demo): version: 1.2.2-dev
> [INFO ] (playground.demo): signature: 20031111.020554
>
> Example source is attached.
>
> Cheers, Steve.
>
> --
>
> Stephen J. McConnell
> mailto:mcconnell@apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [repository] mime type addition?
Posted by Stephen McConnell <mc...@apache.org>.
Based on some help from Erik Abele on infrastructure I was able to
sort this one out. Erik put together a test case in C to validate
that the Apache server was doing its thing with respect to content
negotiation - which left me with the problem of resolving the issues
with the Java approach.
Detailed below are the issues and solutions.
Stephen McConnell wrote:
>
> Have started some experimentation with content negotiation
> and I think I need a mime type addition to server running
> www.apache.org.
>
> I have setup the following test content:
>
> http://www.apache.org/~mcconnell/
>
> This contains a single jar file and a test file containing
> metadata about the jar file.
>
> example.jar
> example.jar.meta
>
> I've also put together a little test case that creates a url
> to the artifact http://www.apache.org/~mcconnell/example
> and then sets the "accept" request parameter to "text/x-meta".
> Presumably the mime type used here ("text/x-meta") needs to be
> declared on the Apache server with a mapping to the ".meta"
> extension.
>
> Does anyone know if this is something I can configure
> in the enclosing directory - or do I need post a request to
> infrastructure?
You can declare MIME type additions by putting in place a .htaccess file
somewhere in the filesystem. For the above example I declared a
"text/x-meta" MIME type using a .htaccess file containing the following:
AddType text/x-meta .meta
>
> Here is a fragment of the relevant java source:
>
> URL url = new URL( "http://www.apache.org/~mcconnell/test/example" );
> URLConnection connection = url.openConnection();
> connection.setRequestProperty( "accept", "text/x-meta" );
The above line contains a bug.
To operate corectly the request property key should be "Accept" (note
that the value is case sensitive).
>
> getLogger().info( "input" );
> InputStream input = (InputStream) connection.getContent();
> Properties properties = new Properties();
> properties.load( input );
>
> Without the mime mapping the above code will result in the stuffing
> of the jar file into the properties file which is not exactly
> what we want.
Using the following URL:
http://www.apache.org/~mcconnell/test/example
I can pull down the meta info using the attached testcase resulting in:
[INFO ] (playground.demo): name: avalon-activation-impl
[INFO ] (playground.demo): group: avalon-activation
[INFO ] (playground.demo): version: 1.2.2-dev
[INFO ] (playground.demo): signature: 20031111.020554
Example source is attached.
Cheers, Steve.
--
Stephen J. McConnell
mailto:mcconnell@apache.org