river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Firmstone <j...@zeus.net.au>
Subject Re: [Discuss] Please have a look at the River Container
Date Thu, 20 Feb 2014 01:39:22 GMT

Haven't had time to participate in the latest conversation.

   1. Would like to see River adopt Rio's conventions at the very least
      as part of the new standard, also like to see Maven provisioning.
   2. Dennis, if you're interested, I'd be prepared to be one of your
      developers for RIO, if you decided to go the incubator route.
   3. Greg, for River container, I think we need to document whether
      certain classes are thread safe or not, using annotations.  Also
      I'd tend to favour constructors for dependency injection, rather
      than fields, since this allows for immutability.
   4. I've found, making old code thread safe is very hard, mutibility
      is very hard.  When you take advantage of immutability, you can
      use java.util.concurrent classes for controlling mutable state, or
      thread confine mutable state, then safely publish when you've
      finished mutating, never mutate again after publishing, but mutate
      a new object and replace the old one instead.

Regards,

Peter.


On 20/02/2014 9:24 AM, Greg Trasuk wrote:
>>> The standard I proposed is what is currently implemented by River-Container.
 Rio’s convention is very much different, and relies on reading jar files from a Maven repository
rather than from the local file system.  It represents a radical departure from the Service-Starter
conventions, although it is compatible with the services.
>> This is false. Rio provides the capability to declare a service be loaded either
by artifact resolution or by using declared jars. I have never moved away from the latter
approach for the simple reason that there are deployments that require legacy support.
> My mistake.  Thank you for the correction.
>
>> Using an artifact to annotate a codebase, or to resolve a service's classpath provides
significant advancement in the build-deploy lifecycle for developers, and also provides performance
benefits when accessing a service's codebase (as well as addressing perm-gen oome for containers).
>>
> Makes a lot of sense.  It’s something I’m intending to look into.
>
>> I'm thinking that way too. For now, I am withdrawing my offer of donating Rio to
River. My intention was that it would greatly benefit River, by dramatically improving the
out of box experience. I'll be happy if River would just mention it as a notable project that
may be beneficial to developers getting to know River.
>>
>> I'll also comment on your service archive standard, and if reasonable (and given
time) I'll provide support for it in Rio.
>>
> I recognize your earlier concerns about the River project appearing to favour one container
over another.  As such I’ll continue development of the River-Container outside the Apache
River project.  I guess it’ll need a new name.
>
> I’m not sure if we should leave River-435 open to discuss the service packaging.  Perhaps
others can comment...
>
>> Regards
>>
>> Dennis
> Cheers,
>
> Greg Trasuk
>
>


Mime
View raw message