On 04/11/10 12:40, Lincoln Baxter, III wrote:
> 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.
>
Actually, EL doesn't know the names of the beans, only the bean contains
do. EL can resolve names with the use of ELResolvers, which the bean
containers provide.
However, IF this is useful, EL can provide an container independent API
for it. This can be done in the BeanLookup interface that I've proposed.
interface BeanLookup {
/* @Return the bean instance with the given name */
Object getBean(String BeanName);
/* @Return the bean type with the given name */
/* Useful for calling static methods of beans that are registered but
not instantiated. */
Class<?> getBeanType(string beanName);
/* @Return the names of the beans with the given type
* or empty set if there is no beans with the given type
* or null if the set is unknown. */
Set<String> getBeanNames(Class<?> beanType);
}
Would this works?
-Kin-man
> 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
> <mailto: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
> <mailto:el-next-unsubscribe_at_uel.dev.java.net>
> For additional commands, e-mail: el-next-help_at_uel.dev.java.net
> <mailto:el-next-help_at_uel.dev.java.net>
>
>
>
>
> --
> Lincoln Baxter, III
> http://ocpsoft.com
> http://scrumshark.com
> "Keep it Simple"