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
