constructs like
if ( personFieldsList == null ) {
getPersonFieldList();
}
where getPersonFieldList() is not thread safe will result in side
effects under-load on statup, you could rewrite this into
if ( personFieldsList == null ) {
personFieldsList = getPersonFieldList();
}
and change getPersonFieldList to be thread safe.
however, if you do this in a seperate bean and guice inject it,
creation of the handler, then there will be no threading issue.
---------------------------
IMHO
the JSON parsing should be handled in a separate set of beans that
are guice injected.
So the only dependency that you really should need to add to the
Handler is the new beans.
HTH
Ian
On 9 Nov 2008, at 18:38, Rajdeep Dua wrote:
Style aspect is easily fixable.
Since container.js is a json based structure and i wanted to re-use
JsonContainerConfig class to get the JSONObject ended up using it.
Are you suggesting not using this class or not having the container.js
parsed and loaded in handlers.
Since handlers are responsible for generating the response
depending on the
request type -- activities or people , that is why i am delegating
this to
them
Can you suggest where else should this be handled ?
For mulithreaded scenarios - there will be issues if we are doing read
write, since this is a read only operation thread synchronization
will
reduce the performance and might not be required.
Thanks
Rajdeep
On Sun, Nov 9, 2008 at 2:58 PM, Ian Boston (JIRA) <[EMAIL PROTECTED]>
wrote:
[
https://issues.apache.org/jira/browse/SHINDIG-560?
page=com.atlassian.jira.plugin.system.issuetabpanels:comment-
tabpanel&focusedCommentId=12646059#action_12646059]
Ian Boston commented on SHINDIG-560:
------------------------------------
I have some concerns about this patch,
Style: It does not conform to the style guide, (white space, full
classnames in the code not in imports etc)
Structure: It has introduced bindings to the JSON parsing
libraries in the
DataHandler which I think is a mistake as these should be
abstracted into
the Bean converter area to generate beans.
I see that there is some request scope loading and parsing of
files which
will probably have issues with thread safety under load when an
appserver is
brought on line in a active community... if its possible to have
concurrent
access, you can bet it will happen.
So, at the moment, I am not inclined to apply this as it stands,
but others
my have different views.
Add support for @supportedFields
--------------------------------
Key: SHINDIG-560
URL: https://issues.apache.org/jira/browse/
SHINDIG-560
Project: Shindig
Issue Type: New Feature
Components: RESTful API (Java)
Reporter: Cassie Doll
Priority: Blocker
Attachments: fix-560-bug.patch, shindigpatch-560.patch
We need to add support for the @supportedFields query on each
handler.
(ie people/@supportedFields, activities/@supportedFields)
Maybe a guice binding to a set of strings or something similar
would make
this work.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
