[
https://issues.apache.org/jira/browse/SHINDIG-1647?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13134208#comment-13134208
]
[email protected] commented on SHINDIG-1647:
--------------------------------------------------------
bq. On 2011-10-21 19:34:35, Jesse Ciancetta wrote:
bq. >
http://svn.apache.org/repos/asf/shindig/trunk/java/common/src/main/java/org/apache/shindig/config/ValueProvider.java,
line 162
bq. > <https://reviews.apache.org/r/2467/diff/3/?file=52114#file52114line162>
bq. >
bq. > Extraneous semicolon
That's what I get for doing JavaScript and Java development at the same time. :)
bq. On 2011-10-21 19:34:35, Jesse Ciancetta wrote:
bq. >
http://svn.apache.org/repos/asf/shindig/trunk/java/common/src/main/java/org/apache/shindig/config/ValueProvider.java,
line 255
bq. > <https://reviews.apache.org/r/2467/diff/3/?file=52114#file52114line255>
bq. >
bq. > I think initialized might need to be declared as volatile for this
double-checked-locking to work properly.
bq. >
bq. > Since this method is really only called when Shindig is initializing
it might be simpler to just synchronize the whole method.
This isn't necessarily called when Shindig is initializing; rather, it's called
the first time anyone needs to get a value of when they add a listener. The
reason to not synchronize the whole method is because I don't want threads to
wait on a no-op in the case of any call after the first.
And yes, I believe you are right that this should be volatile in this case, so
long as I keep the synchronization around the read/write of its value.
- Stanton
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/2467/#review2753
-----------------------------------------------------------
On 2011-10-24 16:28:55, Stanton Sievers wrote:
bq.
bq. -----------------------------------------------------------
bq. This is an automatically generated e-mail. To reply, visit:
bq. https://reviews.apache.org/r/2467/
bq. -----------------------------------------------------------
bq.
bq. (Updated 2011-10-24 16:28:55)
bq.
bq.
bq. Review request for Ryan Baxter, Dan Dumont and Jesse Ciancetta.
bq.
bq.
bq. Summary
bq. -------
bq.
bq. This patch adds an abstraction layer between implementations and
configuration. The patch consists of an abstract class and some interfaces
that are used to read and observe ContainerConfig. Implementors of this class
could decide to read their configuration from ContainerConfig or provide values
from another source. This also allows code that needs to use configuration to
not have to worry about managing container.js keys. They can simply ask their
provider for values.
bq.
bq. I've separated this out from another review as it is generic. To see an
implementation of ValueProvider, you can look at this review:
https://reviews.apache.org/r/2362
bq.
bq.
bq. This addresses bug SHINDIG-1647.
bq. https://issues.apache.org/jira/browse/SHINDIG-1647
bq.
bq.
bq. Diffs
bq. -----
bq.
bq.
http://svn.apache.org/repos/asf/shindig/trunk/java/common/src/main/java/org/apache/shindig/config/ValueProvider.java
PRE-CREATION
bq.
bq. Diff: https://reviews.apache.org/r/2467/diff
bq.
bq.
bq. Testing
bq. -------
bq.
bq. No specific testing done on the patch, but testing was done in the other
review for those classes that implement and use it.
bq.
bq.
bq. Thanks,
bq.
bq. Stanton
bq.
bq.
> Provide an abstraction between implementations and the configurations they use
> ------------------------------------------------------------------------------
>
> Key: SHINDIG-1647
> URL: https://issues.apache.org/jira/browse/SHINDIG-1647
> Project: Shindig
> Issue Type: New Feature
> Components: Java
> Affects Versions: 3.0.0
> Reporter: Stanton Sievers
> Fix For: 3.0.0
>
>
> Add an abstraction layer between implementations and configuration. The
> patch consists of an abstract class and some interfaces that are used to read
> and observe ContainerConfig. Implementors of this class could decide to read
> their configuration from ContainerConfig or provide values from another
> source. This also allows code that needs to use configuration to not have to
> worry about managing container.js keys. They can simply ask their provider
> for values.
> I've separated this out from another review as it is generic. To see an
> implementation of ValueProvider, you can look at this review:
> https://reviews.apache.org/r/2362
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
