Hmmm -- You're right. I don't see the necessary interfaces or semantics that
would let us simple "expose" this information. The bean-containers certainly
have the information, but they aren't providing it to EL right now. They
register Contexts, but those contexts aren't required to provide any kind of
Map interface that would allow such a reverse-lookup.
That's not to say we couldn't push for it, but.. a universal/modular
adapter (as you suggested) would be simpler to provide (separately from the
EL).
--Lincoln
On Fri, Apr 16, 2010 at 5:53 AM, Martin Marinschek <
martin.marinschek_at_gmail.com> wrote:
> Hi Lincoln,
>
> well, do you really know if all the bean-containers have such an API -
> give me the list of names per type? the usual API will be "give me the
> bean for a name" - this is slightly different from the usual case.
>
> best regards,
>
> Martin
>
> On Thu, Apr 15, 2010 at 4:54 PM, Lincoln Baxter, III
> <lincolnbaxter_at_gmail.com> wrote:
> > Why do bean-containers need to implement anything new? The contexts are
> > already being registered with EL - we're just exposing the naming
> > information, right? EL looks up the names based on the type we give it
> (in
> > the case of this new API), or visa versa.
> >
> > I'm not a bean-container expert, so I may have that wrong, though. I
> thought
> > this information was already available.
> >
> > --LB
> >
> > On Thu, Apr 15, 2010 at 2:25 AM, Martin Marinschek
> > <martin.marinschek_at_gmail.com> wrote:
> >>
> >> 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
> >>
> >> ---------------------------------------------------------------------
> >> 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
>
> ---------------------------------------------------------------------
> 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"