On May 19, 2010, at 1115AM, Patrick Wright wrote: > On Wed, May 19, 2010 at 4:46 PM, Dennis Reedy <[email protected]> wrote: >> >> On May 19, 2010, at 1007AM, Patrick Wright wrote: >> >>> It seems you would want >>> - the service to post a hash of the required dependency/DL JAR file >>> that it expects you to use; this not only helps guarantee >>> authenticity, >> >> True, but I suggest that in general you already know what these are. You >> would need to in order to build your client (or service) that uses the >> associated service. > > Yes, what I meant though was that when the service launches, it may or > need to register (via Entries) identifying information for the DL JAR, > in case that has changed. If it's posted via the entry (or even the > codebase attribute) then the client will know whether it has the JARs > or not, whether it has the correct version, and whether it needs to > download them.
Sure, having a 'standard' entry thats part of the platform would allow a client to determine what it would need to download (if anything). > > Of course, this isn't necessary. It just allows for a little more > dynamic behavior in case you deploy services and clients on different > cycles, and the client is deployed with access to an older version of > the DL JAR. If you deploy both sides at the same time, you wouldn't > need this. I havent seen this issue, the resolution of what the client needs is known in advance (assuming you buy into having a priori knowledge of what you need in advance, and in general I suggest that you do). > > I think the Maven coordinate would work as well, but I have had Maven > burp every now and then and I need to delete artifacts from my local > repository to clear up some confusion it has with an older artifact. Certainly having a failsafe to allow a local repository's artifact(s) to be cleared up is needed (we have seen this as well). > Hence I suggest a hash as a more accurate key to verifying we have the > right JAR. True (I suppose), I would just suggest that another format for downloading and storing artifacts would in general be not advisable. Using incumbent and widely adopted approaches is preferred. Regards Dennis
