Ok, so Kin-Man has given a proposal for the implementation, but the
use-case hasnīt been discussed to the end.
Interesting use-case, Lincoln - but I am not sure everybody will agree
this is universally useful. I think you will have to parse the
standard annotations to find out the name (I do think that in the end
people will end up using the standard annotations as far as possible
anyways).
best regards,
Martin
On Mon, Apr 12, 2010 at 11:45 PM, Lincoln Baxter, III
<lincolnbaxter_at_gmail.com> wrote:
> 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"
>
--
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces