Integrating DWR and Weld: @Named implicitly: How to get the name?

[luxspes]

I am implementing an extension to integrate Weld and DWR.
For DWR to integrate with Weld, I need to create a wrapper class implementing the interface org.directwebremoting.Container

One of the methods in that interface is public Collection getBeanNames() that returns a list with the names of all the beans
that will be remoted by DWR.

Now, BeanManager does not have a method that returns all the beans that are annotated with a particular annotation (in this the created-by-me com.googlecode.solder.dwr.DwrBean)
But Gavin told me that:

You would have to write an Extension that builds the list of classes as the bean archives are being scanned, by observing ProcessAnnotatedType.

I have done that... and I hope that it works... but I have a problem once I have the list with all the AnnotatedType<DwrBean> I need to get the name.
Now, for named beans, Weld proportionates the @Named annotation... that would be enough for cases where the name is set explicitly: @Named("someName") class SomeName{} all I have to do
is get the @Named object and ask for its value(), but... what to do if my bean is named implicitly: @Named class SomeName{}.

I guess I should assume that the name in those cases is the name of the class with the first letter in lowercase...is that recommended? or should I be obtaining the name in another way?
The thing that worries my about just changing the first letter of the class name to lowercase if @Named.value() is empty is that I do not know if Weld does some special name conflict resolution in cases like this:

package somePackage;
@Named class SomeName{}

package otherPackage;
@Named class SomeName{}

In this cases... both classes get the someName name? or Weld detects there is a conflicts and atomatically prepends the name of the package?

[swd847]

I think that would be a definition error, but I am not sure. Don't forget that if a stereotype is annotated @Named then the bean is implicitly named as well.

[swd847]

Can you do:

Set<Bean<?>> beans = manager.getBeans(Object.class, new DwrBeanLiteral());
for(Bean b : beans)
{
  String name = b.getName();
}

where DwrBeanLiteral is

public class DwrBeanLiteral extends AnnotationLiteral<DwrBean> implements DwrBean {};

and the manager is looked up from JNDI?

[luxspes]

Yeap, I was starting to think that using manager.getBeans would be much less complicated... I guess I got confused because in Spring something  like manager.getBeans would return actual bean instances... but apparently in Weld that returns beans definitions (to create bean instances I should instead use createInjectionTarget.
Guess I got confused...
Thanks a lot!

[luxspes]

I am still confused... now... if manager.getBeans(nameInString)  gets me all the bean definitions for that name... how do I get a bean instance from that  bean definition?

[swd847]

Try this:

CreationalContext cc = manager.createCreationalContext(bean);
Object beanInstance =  manager.getReference(bean, type, cc);

Bean is the Bean object and type is the Java class of the Bean. I'm not sure if this is the official way of doing it.

[gavin.king]

To get all beans, you can use BeanManager.getBeans(Object.class, new AnnotationLiteral<Any>(){}).

To get all beans with a @Named annotation, you can use BeanManager.getBeans(Object.class, new AnnotationLiteral<Named>(){}), since @Named is a qualifier.

:-)

[gavin.king]

Stuart Douglas wrote on Nov 22, 2009 06:48:



Try this:

CreationalContext cc = manager.createCreationalContext(bean);
Object beanInstance =  manager.getReference(bean, type, cc);

Bean is the Bean object and type is the Java class of the Bean. I'm not sure if this is the official way of doing it.

Yes, that's correct.

[luxspes]

Thanks to Stuart! Thanks to Gavin! Weld is great!

[luxspes]

My code looks like this:

         Bean<?> beanDefinition = getBeanDefinition(id);
         CreationalContext cc = beanFactory.createCreationalContext(beanDefinition);
         Object beanInstance =  beanFactory.getReference(beanDefinition, beanDefinition.getBeanClass(), cc);

I just wonder... why I can not just do this:

         Bean<?> beanDefinition = getBeanDefinition(id);
         CreationalContext cc = beanFactory.createCreationalContext(beanDefinition);
         Object beanInstance =  beanFactory.getReference(beanDefinition, cc);

After all the beanDefinition knows the beanClass... why getReference needs 2 parameters?

[swd847]

I thinks its for session beans where you can have 2 distict local interfaces, and no bean class, so you need to pick which interface you want.

[gavin.king]

Stuart Douglas wrote on Nov 22, 2009 09:59:


I thinks its for session beans where you can have 2 distict local interfaces, and no bean class, so you need to pick which interface you want.

Also for managed beans where the bean class is unproxyable, but has some other bean type that is proxyable.

There can even be some more exotic cases with custom beans.