What parameter should @Requires use - and what should @Requires do?

[brandizzi]

Seam Solder documentation says that the @Requires annotation requires an array of Class objects as a parameter. However, when I try to use it (from Seam Solder 3.0.0.Final API artifact - not the impl artifact, it is worth noting) Eclipse informs me the annotation expects an array of strings. Some source code I have found also indicates the annotation requires strings

This is a clear problem in documentation and I could deal with it by only using the fully qualified name of the required class in a string. I tested it and in fact I can veto a class making it dependable of a class. For example, if I have some interface with no implementation

public interface MyBean {
}

I can veto the processing of a bean using @Requires referring to a nonexistent implementation:

@Requires("com.example.beans.impl.MyBeanImpl")
public class DependentBean {
    @Inject private MyBean myBean;
}

What does bug me is that I cannot veto the DependentBean by making it dependable of any implementation of MyBean. If I have both the DependentBean and the MyBean interface, but no suitable implementation of MyBean, in an application, the code below does not veto the dependent bean, although there is no bean candidate to fill the dependency:

@Requires("com.example.beans.MyBean")
public class DependentBean {
    @Inject private MyBean myBean;
}

Looking at the example of the Seam 3 Reference Guide, I believed the purpose of the @Requires annotation is to veto the annotated class if there is no bean satisfying the bean type passed as parameter.

So, my question is: should @Requires veto the processing of a class if the bean type passed as parameter to the annotation has no available bean? If so, wouldn't  it be better to pass a type object as parameter for @Requires instead of a string as the reference guide purposes?

[lightguard]

IIRC, it takes a string to avoid the application blowing up when the class is loaded if the class mentioned in the @Requires isn't on the classpath. It should be fixed in the documentation though. Please create a JIRA for the doc issue in Solder.

[jharting]

Also, @Requires handles classpath level requirements. It does not handle requirements on a CDI Bean level. If you need that, please create a feature request in JIRA.

[brandizzi]

Jason Porter wrote on Sep 12, 2011 22:28:

It should be fixed in the documentation though. Please create a JIRA for the doc issue in Solder.

I submitted a pull request to the Solder project on GitHub. Do you think I should post a bug report too?

(I am not really sure about how to deal with Seam 3 bugs. The project page seems to encourage the use of GitHub. I am new to the Seam community after all :) )

Jozef Hartinger wrote on Sep 13, 2011 10:18:

Also, @Requires handles classpath level requirements. It does not handle requirements on a CDI Bean level. If you need that, please create a feature request in JIRA.

I imagined that @Requres managed CDI-level dependencies because the problematic documentation - I really do not need it. However, it seems to me that CDI-level dependency-based vetoing of classes would make more sense than a veto based on a mere lookup in the classloaders. Do you all think that I am wrong in this point?

[lightguard]

Adam Victor Brandizzi wrote on Sep 13, 2011 11:28:

Jason Porter wrote on Sep 12, 2011 22:28:

It should be fixed in the documentation though. Please create a JIRA for the doc issue in Solder.

I submitted a pull request to the Solder project on GitHub. Do you think I should post a bug report too?

(I am not really sure about how to deal with Seam 3 bugs. The project page seems to encourage the use of GitHub. I am new to the Seam community after all :) )

A pull request is great, I missed that you create one. We're using GitHub for VCS and JIRA for bug tracking.

Adam Victor Brandizzi wrote on Sep 13, 2011 11:28:

Jozef Hartinger wrote on Sep 13, 2011 10:18:

Also, @Requires handles classpath level requirements. It does not handle requirements on a CDI Bean level. If you need that, please create a feature request in JIRA.

I imagined that @Requres managed CDI-level dependencies because the problematic documentation - I really do not need it. However, it seems to me that CDI-level dependency-based vetoing of classes would make more sense than a veto based on a mere lookup in the classloaders. Do you all think that I am wrong in this point?

You could create an extension, which is what Solder is doing and simple issue the veto() call on the ProcessAnnotatedType. Take a look at http://docs.jboss.org/cdi/api/1.0/javax/enterprise/inject/spi/ProcessAnnotatedType.html. I believe there also some talk going on for something else in this space in CDI 1.1.

[jharting]

I imagined that @Requres managed CDI-level dependencies because the problematic documentation - I really do not need it. However, it seems to me that CDI-level dependency-based vetoing of classes would make more sense than a veto based on a mere lookup in the classloaders. Do you all think that I am wrong in this point?

Classloader lookup is vital for implementing optional parts of a CDI extension. Take a CDI extension that supports multiple templating engines as an example. Support for a particular templating engine (e.g. FreeMarker) is optional and you do not want your beans dealing with it to be registered if FreeMarker is not available. In this case bean-level dependency does not help much since the FreeMarker jar contains no CDI beans. With the current semantics of @Requires, you can make an entire package depend on a particular FreeMarker class instead.

You could create an extension, which is what Solder is doing and simple issue the veto() call on the ProcessAnnotatedType. Take a look at http://docs.jboss.org/cdi/api/1.0/javax/enterprise/inject/spi/ProcessAnnotatedType.html. I believe there also some talk going on for something else in this space in CDI 1.1.

This would be kind of tricky to implement since at the time ProcessAnnotatedType is fired, you have no way of detecting whether a bean of particular type (and perhaps qualifiers) is available or not, since this is way before the container is fully initialized.

[brandizzi]

Jozef Hartinger wrote on Sep 13, 2011 14:06:

Classloader lookup is vital for implementing optional parts of a CDI extension. Take a CDI extension that supports multiple templating engines as an example. Support for a particular templating engine (e.g. FreeMarker) is optional and you do not want your beans dealing with it to be registered if FreeMarker is not available. In this case bean-level dependency does not help much since the FreeMarker jar contains no CDI beans. With the current semantics of @Requires, you can make an entire package depend on a particular FreeMarker class instead.

Well, your explanation clarifies the situation to me, and I understand the purpose of @Requires much better now. Thank you, Jozef.

Just one more question: so is @Requires a tool designed more for frameworks developers, then?