You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@shindig.apache.org by Paul Lindner <li...@inuus.com> on 2010/03/02 11:26:26 UTC

Re: JSecurity usage and sample code in social-api project

Thanks for doing this Han,  this will also go a long way towards making a
clean archetype that people can use as a basis for their own
implementations.

Note that there already is a java/samples directory that contains the
hibernate example implementation.  Are you proposing placing that there?

Another potential place to move this is the java/server module, which
functions in some way as an integration point as well.



On Fri, Feb 26, 2010 at 1:14 PM, Han Nguyen <hn...@us.ibm.com> wrote:

> Hi,
>
> While doing a code scan for opensource legal approval to use Shindig in
> our software products, we have some concerns on jsecurity cryptographic
> referenced in the social-api/org.apache.shindig.social.sample.SampleRealm.
> This class is used by SampleModule, which is an example for developers to
> follow to build their own production ready GUICE module.
>
> Since this code is used just for examples, one thing we'd like to do is
> restructure the code to make it easier to tease it out from the core of
> shindig. In Shindig core projects (social-api, gadgets, common, etc.)
> there's a "samples" project where this code resides. We think it makes
> sense to move the whole social-api/org.apache.shindig.social.sample to the
> samples folder. Refactoring the code out from social-api will keep the
> project clean of sample code.
>
> We've tested this refactoring out and have not run into any issues. There
> are, of course, a few configuration steps that we had to do:
> 1. We added "samples" project to the buildpath to point to the new
> location of the package so that shindig-project code would compile.
> 2. We added "samples" project dependency in the main pom.xml and the
> server pom.xml so that the war includes the sample code and wouldn't break
> the sample container examples.
> 3. We're currently investigating how to create an additional server maven
> build profile so that we can build a war without the sample code for
> production usage. In this scenario, it's expected that the user will add
> in their own GUICE module that provides similar functionality as
> SampleModule/ SampleRealm. IF they don't do that, the war will very likely
> be broken and unusable, but since we're all required to implement our own
> GUICE module for this case, a drop of a jar of some similar method should
> fix this. We will document these steps so everyone is on the same page.
>
> We will open a JIRA bug for this effort, any other suggestion and/or
> solution is welcome.
>
> Thanks,
> Han
>