Exactly the scenario I mentioned above ;) Someone creates a framework (like
prettyfaces) and wants to provide annotation support, but doesn't want to
depend on CDI, Spring, Juice, or other implementations. However, there *is*
a dependency on EL, which ends up being an abstraction over these
containers.
Because EL already knows the names of the beans, and the classes of the
beans (I think?) it can probably generate a list of names for each Bean
Class. This would allow products to invoke EL via annotations without
knowing which Bean-container is in use -- there may even be multiple
bean-containers.
It would be possible to write extensions for each bean-container, but
resolving against the EL would be much more portable, since it is already
the home for bean names in Java EE / Java web-tier.
--Lincoln
On Fri, Apr 9, 2010 at 6:43 AM, Pete Muir <pmuir_at_redhat.com> wrote:
> What scenarios do you see this being useful in?
>
> On 1 Apr 2010, at 00:06, Lincoln Baxter, III wrote:
>
> > I'm seeing benefit for a TypeMapper or NameMapper off of the ELContext
> object.
> >
> > When working with Bean Containers, each container has a different API for
> looking up beans and getting information about them. For instance, if I
> wanted to know what names were associated with a bean of type
> "com.ocpsoft.MyBean," there's currently no way of doing that through EL. I
> can go out to the bean containers themselves in order to get that
> information, but EL hides it.
> >
> > The use case:
> > I've annotated a class, and a method on that class, and want to use that
> annotation to invoke an operation on that bean:
> >
> > @ExtensionDefined
> > @javax.enterprise.context.Named("something")
> > public class MyBean {
> >
> > @ExecuteThis
> > public void action() {}
> >
> > }
> >
> > The custom annotations' scanner has access to the Class Type, but without
> providing direct support for Spring, CDI, Seam, Guice, JSF, etc -- has no
> idea what that class is named in the EL.
> >
> > The ELContext has hooks into whatever bean-container backs it (if there
> even is one -- it could be completely custom) and can provide names for a
> given type.
> >
> > So:
> >
> > @Inject ELContext context; //assume this works for example purposes...
> > TypeMapper mapper = context.getTypeMapper();
> > Set<String> names = mapper.getNames(Class<?> clazz); // lists all names
> for which the provided type is registered.
> >
> > This is a very rough concept, but what do you think? I think the value is
> there, but specifics need to be worked out.
> >
> > --
> > Lincoln Baxter, III
> > http://ocpsoft.com
> > http://scrumshark.com
> > "Keep it Simple"
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: el-next-unsubscribe_at_uel.dev.java.net
> For additional commands, e-mail: el-next-help_at_uel.dev.java.net
>
>
--
Lincoln Baxter, III
http://ocpsoft.com
http://scrumshark.com
"Keep it Simple"