[rhetorical] Should AttributeResolver implement the Resolver interface ?

[Cantor, Scott]

On 11/11/13, 5:24 AM, "Rod Widdowson" <rdw at steadingsoftware.com> wrote:
>
>Yea, locking is what V2 uses.   My problem with locks is that unless you
>code them carefully they end up turning localized hangs or stalls into a
>systemwide ones.   But implemented carefully they are functionally
>equivalent of a refcount.  Further, although I'd claim that the V2
>implementation is not as carefully done as I'd like we haven't had any
>reports of the misbehavior which I know this design could engender so I'm
>probably over-reacting.

Well, we did have at least one major issue with the relying-party file
reloading.

>I'd disagree with you.  But I'm not going to die in a ditch for it - it¹s
>just a detail.   After all dropping a shared lock or dropping a refcount
>are
>just implementations behind the doneWithServiceableComponent() call..  I
>probably let myself be overly influenced by experiences which are not
>necessarily relevant in this sphere...

I think the main point is the Closeable thing, the code is a lot cleaner
with try-with-resources.

I think if you use a shared lock, the outcome is really the same, a
hanging ref count that prevents reloading, but doesn't deadlock. But that
may be dependent on how many recursive locks it allows.

>My concern is that there are several actions (e.g. ResolveAttributes,
>EncodeAttributes) which all run from the same configuration.    If we want
>to guarantee that all actions in the same webflow run from the same
>configuration your lock (or pin) has to span the call to both actions (or
>invent some other mechanism).  If we can live with the potential
>disjunction
>it's not an issue of course.

I think we have to. You can't hold a lock or a reference count across
actions and expect a robust system, and once you start doing that, you
have a real problem with injecting views into the webflow. It's crucial
IMHO that we allow views to be in the mix without needing to worry about
the impact on the surrounding actions.

All that said, I think Marvin's point is valid. If we can actually reload
the entire context safely with Spring alone, I think that's worth
considering in place of doing this piecemeal.

I'm not saying I think we can, necessarily, but if it's really possible...

-- Scott