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"