That would be perfect!
That's exactly what I'm looking for -- I think I was having some trouble
really explaining clearly; every time I try to do it, I've been traveling
for 50 hours.
--Lincoln
On Mon, Apr 12, 2010 at 4:54 PM, Kin-man Chung <kinman.chung_at_oracle.com>wrote:
> 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> 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"
>
>
>
--
Lincoln Baxter, III
http://ocpsoft.com
http://scrumshark.com
"Keep it Simple"