I'm sure I'm not being clear ;)
Let me ask a question.
Assuming the following constraint:
- No given dependencies to any one given bean-container, just knowledge
that a bean container exists, and that it is registered with the ELContext
How would you write a bean-container-portable extension (spring, guice, cdi,
faces, other...,) using annotations, to invoke methods on Beans via EL?
@Named("service") //CDI
public class BusinessService {
@InvokeBefore(RENDER_RESPONSE)
public String doSomething()
{
return "success";
}
}
In this scenario, @InvokeBefore should be the equivalent of using EL:
#{service.doSomething()}
--Lincoln
On Mon, Apr 12, 2010 at 7:44 AM, Pete Muir <pmuir_at_redhat.com> wrote:
>
> On 11 Apr 2010, at 20: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
>
> I'm sure I'm being obtuse, but I don't understand what this means, let
> alone how you would use it....
>
> > without knowing which Bean-container is in use -- there may even be
> multiple bean-containers.
> >
> > 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"
>
>
> ---------------------------------------------------------------------
> 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"