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