[ 
https://issues.apache.org/jira/browse/SHINDIG-805?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12658238#action_12658238
 ] 

Henning Schmiedehausen commented on SHINDIG-805:
------------------------------------------------

I looked briefly into ripping out ContainerConfig, unfortunately the rewriter 
needs it in InjectBaseTag (to look up whether it should inject the base tag or 
not). Turning the block at the beginning of getLibraryConfig into a contributor 
would require to add a Collection<GadgetSpec> onto the contribute() method 
signature, because this collection is created using the forced libs in 
getFeatures. And *that* can not be made static because it requires a reference 
to the featureRegistry (which in turn is injected into the rewriter). So 
unwinding this block might only work if you actually pull out the code into an 
inner class implementing ConfigContributor but then again, it would still be 
inseparately married to the RenderingContentRewriter. And you would need to 
inject it using Guice which makes it awkward, because you would need a provider 
which gives you an object specific to the RCR. Which in turn is simply not 
worth the hassle. :-)



> Modularize contributors to gadgets.config.init and make them injectable
> -----------------------------------------------------------------------
>
>                 Key: SHINDIG-805
>                 URL: https://issues.apache.org/jira/browse/SHINDIG-805
>             Project: Shindig
>          Issue Type: Improvement
>          Components: Common Components (Java)
>    Affects Versions: 1.0.x-incubating
>            Reporter: Henning Schmiedehausen
>         Attachments: SHINDIG-805, SHINDIG-805-2.patch
>
>
> In the RenderingContentRewriter, some content of the gadget.config.init is 
> generated on the Java side and then injected to Javascript (i.e. it is not 
> pulled from the features registered). This currently is the feature 
> configuration for core.util (which has another bug, see SHINDIG-803) and the 
> shindig.auth creation. Both of these are hard coded.
> In our use case, we need to contribute additional fields for platform 
> specific configuration elements, which is best done on the Java core side. 
> This patch pulls out the two pieces into ConfigContributors and makes these 
> configureable and injectable through Guice, thus allowing integrators to add 
> their own Contributors without having to patch the Shindig code.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Reply via email to