Re: the p2.index file. This only instructs p2 for which 'types' of repositories to load. The 'type' is indexed by a key. In the case of composite metadata repositories, the key is compositeContent.xml. This says nothing about the file names to load (these are handled by the particular extension that implements this repository type). So the file could bee foo.txt for all we know.
Now, it happens that composite metadata repos check compositeContent.jar and composƒiteContent.xml (and it uses a particular search order, .jar first I think). As for the access denied, yes, I know AWS does this (and some consider this a good security measure, since you can't figure out the difference between accessed denied and not available). The transport layer _should_ fail fast in this case and move on to the xml file. What version of p2 are you using? I know this was a problem a while ago, but it was fixed (IIRC 3.6.1). Cheers, Ian On Fri, Jan 6, 2012 at 8:08 AM, Henrik Lindberg < [email protected]> wrote: > Odd that the information in the p2.index does not seem to be honoured. > Maybe it continues if there is a problem delivering it (timeout), but I > don't really know the logic around the p2.index file. This is Ian Bull's > domain IIRC. > > Regarding delivering an access denied status when a not found (404) should > have been delivered is never good as you are basically saying "the file is > there but you are not allowed to read it". > > One potential source of problems is if the update site has changed over > time, and user once got hold of index information (in jars or xml files) > that are no longer present - I can imagine checks being made in those cases > for those specific files even if the p2.index file says otherwise. In this > case delivering an access denied instead of 404 does not give the p2 client > side a chance to correctly update the cached information as it will > continue to believed the file is there. (I am just speculating though). > > Hope that is of some help. > Regards > Henrik Lindberg > [email protected] > > > > On Jan 6, 2012, at 15:21, Martin Lippert wrote: > > Hi! > > I am facing an interesting problem with update sites and I hope you can > help me understand what is going on. We have plenty of composite update > sites that all contain just an "compositeArtifact.xml" and a > "compositeContent.xml" file. Those files work nicely. > > But we are quite often getting reports from users that their installation > stalls when they check for updates, complaining about "content.jar" could > not be found (with a read timeout), same for "compositeArtifact.jar" or > similar. Even if I put up a p2.index file like this: > > version=1 > metadata.repository.factory.order=compositeContent.xml,! > artifact.repository.factory.order=compositeArtifacts.xml,! > > it doesn't change much, the "check for updates" is again complaining about > a missing file "compositeArtifact.jar". > > I don't know why and what to do about this. > > One thing that is special here is the fact that our server (Amazon S3) is > serving an XML document (containing an access denied error) when a resource > is not found (like it is the case for those resources that p2 seems to try > to download. > > Any idea what I can do about this? > > Thank you very much in advance for your help!!! > > Cheers, > -Martin > > _______________________________________________ > p2-dev mailing list > [email protected] > https://dev.eclipse.org/mailman/listinfo/p2-dev > > > > _______________________________________________ > p2-dev mailing list > [email protected] > https://dev.eclipse.org/mailman/listinfo/p2-dev > > -- R. Ian Bull | EclipseSource Victoria | +1 250 477 7484 http://eclipsesource.com | http://twitter.com/eclipsesource
_______________________________________________ p2-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/p2-dev
