You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@abdera.apache.org by James M Snell <ja...@gmail.com> on 2007/08/28 17:08:56 UTC
0.3.0 branch created
Please kick the tires, check the oil, etc etc. The zips have been
rolled and are available at:
http://people.apache.org/~jmsnell/abdera/0.3.0/abdera.0.3.0-incubating.zip
http://people.apache.org/~jmsnell/abdera/0.3.0/abdera.0.3.0-incubating.jdk142.zip
http://people.apache.org/~jmsnell/abdera/0.3.0/abdera.0.3.0-incubating.src.zip
- James
Re: 0.3.0 branch created
Posted by James M Snell <ja...@gmail.com>.
I haven't found any additional bugs. Here's my +1
- James
Brian Moseley wrote:
> On 8/30/07, James M Snell <ja...@gmail.com> wrote:
>> Doh! You're right. I completely missed that one. I've updated EntityTag
>> in trunk and the 0.3.0 branch so that the * is supported. If you would,
>> please give it another shot. There's no reason to rush so we can
>> definitely wait until you've had another chance to look it over. I'll
>> roll the new zip's in a couple of minutes.
>
> looks good. thanks for the quick turnaround. i say ship it!
>
Re: 0.3.0 branch created
Posted by James M Snell <ja...@gmail.com>.
Fixed. Take another look. New zips uploaded.
- James
Ugo Cei wrote:
>
> On Sep 1, 2007, at 7:28 PM, James M Snell wrote:
>
>> Anyone else have a chance to look over the new zips yet?
>
> Just found what seems to be a problem in the Spring module: the Ant
> build does not include in the abdera-spring jar a copy of the schema
> and schema resolver configuration files that are in
> spring/src/main/resources/META-INF.
>
> Without these, the XML schema validator tries to download the schema
> from <http://abdera.apache.org/schemas/abdera-spring.xsd> (which does
> not resolve) instead of reading it from a classpath resource.
>
> Ugo
>
>
Re: 0.3.0 branch created
Posted by Ugo Cei <ug...@gmail.com>.
On Sep 1, 2007, at 7:28 PM, James M Snell wrote:
> Anyone else have a chance to look over the new zips yet?
Just found what seems to be a problem in the Spring module: the Ant
build does not include in the abdera-spring jar a copy of the schema
and schema resolver configuration files that are in spring/src/main/
resources/META-INF.
Without these, the XML schema validator tries to download the schema
from <http://abdera.apache.org/schemas/abdera-spring.xsd> (which does
not resolve) instead of reading it from a classpath resource.
Ugo
Re: 0.3.0 branch created
Posted by James M Snell <ja...@gmail.com>.
Anyone else have a chance to look over the new zips yet?
- James
Brian Moseley wrote:
> On 8/30/07, James M Snell <ja...@gmail.com> wrote:
>> Doh! You're right. I completely missed that one. I've updated EntityTag
>> in trunk and the 0.3.0 branch so that the * is supported. If you would,
>> please give it another shot. There's no reason to rush so we can
>> definitely wait until you've had another chance to look it over. I'll
>> roll the new zip's in a couple of minutes.
>
> looks good. thanks for the quick turnaround. i say ship it!
>
Re: 0.3.0 branch created
Posted by Brian Moseley <bc...@osafoundation.org>.
On 8/30/07, James M Snell <ja...@gmail.com> wrote:
> Doh! You're right. I completely missed that one. I've updated EntityTag
> in trunk and the 0.3.0 branch so that the * is supported. If you would,
> please give it another shot. There's no reason to rush so we can
> definitely wait until you've had another chance to look it over. I'll
> roll the new zip's in a couple of minutes.
looks good. thanks for the quick turnaround. i say ship it!
Re: 0.3.0 branch created
Posted by James M Snell <ja...@gmail.com>.
Doh! You're right. I completely missed that one. I've updated EntityTag
in trunk and the 0.3.0 branch so that the * is supported. If you would,
please give it another shot. There's no reason to rush so we can
definitely wait until you've had another chance to look it over. I'll
roll the new zip's in a couple of minutes.
- James
Brian Moseley wrote:
> On 8/28/07, James M Snell <ja...@gmail.com> wrote:
>> Please kick the tires, check the oil, etc etc. The zips have been
>> rolled and are available at:
>>
>> http://people.apache.org/~jmsnell/abdera/0.3.0/abdera.0.3.0-incubating.zip
>> http://people.apache.org/~jmsnell/abdera/0.3.0/abdera.0.3.0-incubating.jdk142.zip
>> http://people.apache.org/~jmsnell/abdera/0.3.0/abdera.0.3.0-incubating.src.zip
>
> i just updated cosmo to use these jars and only ran into one problem.
> it was using a snapshot of 0.3.0 from before the great server package
> reorganization, so most of the work was just updating import
> statements and moving to Resolver and ItemManager.
>
> the problem i found is that AbstractRequest doesn't handle the case
> where a client sends an If-Match or If-None-Match header with the
> value "*", which indicates "any entity for the resource". this was ok
> when Request.getIfMatch and Request.getIfNoneMatch returned String
> instead of EntityTag[], but now there's no good way to handle this
> case other than looking at getHeader("If-Match") directly, which is
> pretty cheesy.
>
> otherwise, my initial testing indicates that all looks good. i'll try
> to make a more extensive whack at it later this week, but don't wait
> for me.
>
Re: 0.3.0 branch created
Posted by Brian Moseley <bc...@osafoundation.org>.
On 8/28/07, James M Snell <ja...@gmail.com> wrote:
> Please kick the tires, check the oil, etc etc. The zips have been
> rolled and are available at:
>
> http://people.apache.org/~jmsnell/abdera/0.3.0/abdera.0.3.0-incubating.zip
> http://people.apache.org/~jmsnell/abdera/0.3.0/abdera.0.3.0-incubating.jdk142.zip
> http://people.apache.org/~jmsnell/abdera/0.3.0/abdera.0.3.0-incubating.src.zip
i just updated cosmo to use these jars and only ran into one problem.
it was using a snapshot of 0.3.0 from before the great server package
reorganization, so most of the work was just updating import
statements and moving to Resolver and ItemManager.
the problem i found is that AbstractRequest doesn't handle the case
where a client sends an If-Match or If-None-Match header with the
value "*", which indicates "any entity for the resource". this was ok
when Request.getIfMatch and Request.getIfNoneMatch returned String
instead of EntityTag[], but now there's no good way to handle this
case other than looking at getHeader("If-Match") directly, which is
pretty cheesy.
otherwise, my initial testing indicates that all looks good. i'll try
to make a more extensive whack at it later this week, but don't wait
for me.