Thanks for this, I'll have a dig around.
Cheers
Dan
On 18/10/2010 20:01, Mark Struberg wrote:
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
