Hi Lincoln,
yes - but essentially you are putting the effort on bean container
vendors to implement this. And really, this is just one of a million
things which might be useful in information coming from the
bean-container, right? We would have to talk to the bean-container
vendors to see if they are interested (and think this is complete
enough, or what the interface would really look like) to implement
this.
I think you could talk to the CDI guys you have inhouse, I could ask
someone from SpringSource on what they say about this feature.
Standard annotations: I think in the long run, all bean containers
will more or less also support the standard annotations from CDI,
either directly or with very small extensions - I mean the named
annotation you would need to parse to know which name you have set for
this bean.
best regards,
Martin
On Tue, Apr 13, 2010 at 4:49 PM, Lincoln Baxter, III
<lincolnbaxter_at_gmail.com> wrote:
> I'd argue that some people will find it useful, so why should we hide the
> information? This will enable a whole new layer of bean-container-agnostic
> extensions for Java EE.
>
> Also, what do you mean by this?
>
> "I do think that in the end people will end up using the standard
> annotations as far as possible anyways."
>
> --Lincoln
>
> On Tue, Apr 13, 2010 at 10:41 AM, Martin Marinschek
> <martin.marinschek_at_gmail.com> wrote:
>>
>> 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
>>
>> ---------------------------------------------------------------------
>> 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"
>
--
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces