river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dennis Reedy <dennis.re...@gmail.com>
Subject Re: Codebase service?
Date Wed, 19 May 2010 15:27:30 GMT

On May 19, 2010, at 1115AM, Patrick Wright wrote:

> On Wed, May 19, 2010 at 4:46 PM, Dennis Reedy <dennis.reedy@gmail.com> 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
Mime
View raw message