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.


View raw message