dumdidum, please look at MyFaces CODI @ProjectStageActivated [1]. The codi-core is completely JSF independent, so this can be used for each and every CDI based project.
LieGrue, strub [1] https://svn.apache.org/repos/asf/myfaces/extensions/cdi/trunk/core/api/src/main/java/org/apache/myfaces/extensions/cdi/core/api/projectstage/ProjectStageActivated.java --- On Mon, 10/18/10, Dan Haywood <[email protected]> wrote: > From: Dan Haywood <[email protected]> > Subject: JSR-299 question (one for Mark or Nour) > To: [email protected] > Date: Monday, October 18, 2010, 6:48 PM > As per [1] , we've started > reorganizing the codebase to distinguish between default > implementations (org.apache.isis.defaults) and alternatives > (org.apache.isis.alternatives). The terminology is > deliberately aligned with JSR-299; my current thinking is > that all the implementations in o.a.isis.alternatives will > be annotated with @Alternatives. > > However... one thing that we currently support with our > homegrown implementation is to select the "most appropriate" > implementation based on something called the deployment > type. So, if running in "exploration" mode/deployment > type, we set up a noop authentication and an in-memory > object store; if running in "prototype" mode then we support > file-based authentication and the in-memory object store; if > running in "production" mode then we set up file-based > authentication and the xml object store. These can all > be overridden from the command line, but these are the > defaults. > > I don't want to get too far ahead of myself here, but I'd > just like to know how JSR-299 can allow us to > programmatically alter what the defaults are. The use > of @Default and @Alternative annotations suggests that > there's no opportunity to do this other than by altering the > classpath, but I'm hoping that I'm wrong here. > > Thoughts? > > Dan > > > [1] https://cwiki.apache.org/confluence/display/ISIS/MavenModules > > >
