That error is very strange, since EJB local references should always be serializable. Bug in glassfish, perhaps?

Basically, @Inject is always better, since:

• it is more typesafe,
• it supports @Alternatives, and
• it is aware of the scope of the injected object.

I recommend against the use of @EJB except for declaring references to remote EJBs.

I wonder whether weld just as Seam 2.x still doesn't support the injection of the remote EJBs.

Introduction of chapter 3 in the 299 spec:

The container provides built-in support for injection and contextual lifecycle management of the following kinds of bean:
...
Resources (Java EE resources, persistence contexts, persistence units, remote EJBs and web services)

Nicklas Karlsson wrote on Nov 28, 2009 21:32:
Introduction of chapter 3 in the 299 spec:

The container provides built-in support for injection and contextual lifecycle management of the following kinds of bean:
...
Resources (Java EE resources, persistence contexts, persistence units, remote EJBs and web services)

It's interesting that the spec mentioned the resources in chapter 3 while the weld doc didn't mention the resources in the chapter 2 ending with the last producer fields.

This is the feature defined in the spec. Is it available with Weld at the same time?

If it is supported in Weld at the same time, which is better for using to inject remote beans. I'm just confused by gavin's words I recommend against the use of @EJB except for declaring references to remote EJBs. Does it mean @EJB better with remote EJBs?

Use @EJB to define a resource. Then inject it into your beans using @Inject.

Does it mean @EJB better with remote EJBs?

For a remote EJB, we can't declare metadata like qualifiers, @Alternative, etc, on the bean class, since the client simply isn't going to have access to that metadata. Furthermore, some additional metadata must be specified that we don't need for the local case (global JNDI name of whatever). So all that stuff needs to go somewhere else: namely the @Produces declaration.

Does that make sense?

OK Gavin, thanks for helping.

Rgds, J.

Thanks for replying. I understand now.

B/c I am stupid, I like platform and fmwks that cater to the KISS principle.

This is not happening here.

IMHO, it seems somewhat strange that we must decide b/n using @Inject and @EJB in EE 6 apps.

Ok, so there seems to be a technical limitation in the case of remote EJBs. But it would have been nice if the EGs somehow eliminated @EJB completely (except for backwards-compatibility for EE 5 apps).

Unfortunately, now it's somewhat confusing and/or you must keep track of yet another rule/detail so you know when to use which annotation.... bah humbug!

B/c I am stupid, I like platform and fmwks that cater to the KISS principle. This is not happening here.

Arbi, if you spent more time on the learning and understanding bit, and less time on the criticizing stuff you don't properly understand bit, you would not be so stupid.

IMHO, it seems somewhat strange that we must decide b/n using @Inject and @EJB in EE 6 apps.

Four posts ago, I gave you a very simple piece of advice, so that you don't need to decide anything. I wrote:

Use @EJB to define a resource. Then inject it into your beans using @Inject.

Other people seem to have understood what I wrote. If you don't understand, why not ask for further explanation, instead of shooting your mouth off?

Ok, so there seems to be a technical limitation in the case of remote EJBs. But it would have been nice if the EGs somehow eliminated @EJB completely (except for backwards-compatibility for EE 5 apps).

@EJB is completely eliminated for local EJBs (except for backward compatibility). There are lots and lots of examples in the CDI spec and Weld documentation of using @Inject to inject local EJBs. And lots of times where I've explained that we strongly recommend the use of @Inject instead of @EJB to inject local EJBs. How could you possibly have missed that? Because you were too busy posting questions and brain-dead criticism instead of actually reading what is already out there?

And if we tried to eliminate @EJB for remote EJBs, then we would need to introduce some new annotation, let's call it @ArbisSpecialEJB in order to tell the container where to go to obtain the reference to the remote EJB. And, of course, @ArbisSpecialEJB would need basically the same members that @EJB already has. Hey, I've got an idea! Why don't we just eliminate @ArbisSpecialEJB and use @EJB for that instead! After all, @EJB already exists and has a shorter name.

Unfortunately, now it's somewhat confusing and/or you must keep track of yet another rule/detail so you know when to use which annotation.... bah humbug!

It's confusing to some people, apparently.

Jesus, in my very first reply in this thread, I wrote:

Basically, @Inject is always better ... I recommend against the use of @EJB except for declaring references to remote EJBs.

I don't know how I could possibly have been more explicit.

It seems more or less related to WELD-305, but I'm not sure that my patch will help you if you don't have a local interface.

Gavin King wrote on Dec 02, 2009 00:55:
Jesus, in my very first reply in this thread, I wrote: Basically, @Inject is always better ... I recommend against the use of @EJB except for declaring references to remote EJBs. I don't know how I could possibly have been more explicit.

In most projects I've worked on, remote EJBs have not been required. So a remote EJB would be an EJB living in an EJB container in a different JVM/process than your app's EJB container.

Ok, so in the atypical cases when a remote EJB is required, you'd do something like this:

@Produces @EJB(ejbLink="../their.jar#PaymentService") 

PaymentService paymentService;

and then inject in your component using this:

@Inject @Produces @EJB(ejbLink="../their.jar#PaymentService") 

PaymentService paymentService;

so the idea being every time you need to inject an instance of this remote EJB, you use @Inject, rather than @EJB. Is this correct? So basically the @EJB is only used once per remote EJB (in the producer definition).

dammit. unfortunately, I have a penchant for complaining, no matter what, no matter where, no matter I'm wrong or right. editing is required for all forums! make it a damn priority.

...............

There is a typo above.

I meant to type:

@Inject 
PaymentService paymentService;

btw, congrats on the EE6 final ballot vote!

@EJB is completely eliminated for local EJBs (except for backward compatibility). There are lots and lots of examples in the CDI spec and Weld documentation of using @Inject to inject local EJBs. And lots of times where I've explained that we strongly recommend the use of @Inject instead of @EJB to inject local EJBs. How could you possibly have missed that? Because you were too busy posting questions and brain-dead criticism instead of actually reading what is already out there?

And if we tried to eliminate @EJB for remote EJBs, then we would need to introduce some new annotation, let's call it @ArbisSpecialEJB in order to tell the container where to go to obtain the reference to the remote EJB. And, of course, @ArbisSpecialEJB would need basically the same members that @EJB already has. Hey, I've got an idea! Why don't we just eliminate @ArbisSpecialEJB and use @EJB for that instead! After all, @EJB already exists and has a shorter name.

As usual most of your points are very valid. congrats. But I don't want a special EJB annotation. All I want is to use one annotation, call it anything you like, @InjectFoo or @Inject, for all object injections in EE6 apps. Your solution using the producer pattern is a workaround to the remote EJB limitation which requires usage of @EJB. So the EE6 developer must use both @EJB and @Inject to inject a remote EJB object. I'd rather use simply and only @Inject.

Now if that's not possible for remote EJB instances, I can live with that, but using only @Inject obviously seems ideal to me, whether I read the entire spec or not...

ok, here are a couple examples to consider.

http://docs.jboss.org/weld/reference/1.0.0/en-US/html_single/#translator

public class TextTranslator implements Serializable { 


   private SentenceParser sentenceParser; 


   @EJB private Translator translator; 

   

   @Inject public TextTranslator(SentenceParser sentenceParser) { 

      this.sentenceParser = sentenceParser; 

   }

   

   public String translate(String text) { 

      StringBuilder sb = new StringBuilder(); 

      for (String sentence: sentenceParser.parse(text)) { 

         sb.append(translator.translate(sentence)).append(". "); 

      } 

      return sb.toString().trim(); 

   }


}

not the usage of @EJB for the POJO above...

@Stateful

@RequestScoped

@Named("translator")

public class TranslatorControllerBean implements TranslatorController {


   @Inject private TextTranslator translator;

   

   private String inputText;

   

   private String translatedText;

   

   public void translate() {

      translatedText = translator.translate(inputText);

   }

   

   public String getText() {

      return inputText;

   }

   

   public void setText(String text) {

      this.inputText = text;

   }

   

   public String getTranslatedText() {

      return translatedText;

   }

   

   @Remove public void remove() {}


}

not the usage of @Inject for the SFSB above...

TextTranslator uses the simple bean (really just a plain Java class!) SentenceParser to parse the sentence and then calls on the stateless bean with the local business interface Translator to perform the translation.

so in a POJO, must you use @EJB to inject a SLSB local business interface or can you use @Inject as well?

As usual most of your points are very valid. congrats.

Here we go.

But I don't want a special EJB annotation. All I want is to use one annotation, call it anything you like, @InjectFoo or @Inject, for all object injections in EE6 apps.

Right. It's called @Inject. It's the only annotation you use to do injection in CDI. CDI does not use @EJB for injection. It uses it for bean definition. (I'm repeating myself here.)

Your solution using the producer pattern is a workaround to the remote EJB limitation which requires usage of @EJB.

Huh? It's not a workaround. It's how you tell CDI where the hell this remote EJB is.

So the EE6 developer must use both @EJB and @Inject to inject a remote EJB object.

Not correct. You use @EJB to tell CDI where this remote object is, and @Inject to inject it. I've now said this about 4 times.

I'd rather use simply and only @Inject.

And I would rather have magical powers to guess what other people are thinking. But I don't.

How the hell, in your proposal, is CDI going to know, when it encounters the following injection point,

@Inject PaymentProcessor pp

where to go to look for the PaymentProcessorBean that exists in a totally different application, on a totally different machine? It uses its magical powers to guess what Arbi was thinking and magically comes up with the global JNDI name of an EJB deployed in a completely different application in a completely different container?

Now if that's not possible for remote EJB instances, I can live with that,

It's not possible. Live with it.

so in a POJO, must you use @EJB to inject a SLSB local business interface or can you use @Inject as well?

No. As I've said 5 times now. That example is showing the use of old code written to Java EE 5 APIs, that already uses @EJB. I don't recommend that approach for new code.

Arbi, this is the end of this thread. I've now told you the same thing 5 times, and you're deliberately trying not to understand me. I don't appreciate that kind of timewasting behavior. I will delete any future posts on this topic.

So the new code should work because the QuoteService is still a "bean-class local view", right? I'm a bit confused, should the EJB implement a @Local interface for this to work? Any help would be appreciated.

No, in this case, QuoteService will not be recognized as a bean class local view. I'm a little upset about this, since I argued strongly that it should be, but the rest of the group disagreed with me, according to reasoning that I don't think was very sound.

From the EJB 3.1 spec:

The bean class must designate that it exposes a no-interface view via its bean class definition or in the deployment descriptor. The following rules apply :

• If the bean does not expose any other client views (Local, Remote, No-Interface, 2.x Remote Home, 2.x Local Home, Web Service) and its implements clause is empty, the bean defines a no-interface view.
• If the bean exposes at least one other client view, the bean designates that it exposes a no-interface view by means of the @LocalBean annotation on the bean class or in the deployment descriptor.
• ...

So you need to add an ugly @LocalBean annotation. Sorry. I hate it too. :-(

you're deliberately trying not to understand me. I don't appreciate that kind of timewasting behavior.

This was unfair, and I shouldn't have said it.

You'll just need to trust me that there really is no simpler way.

Behold! the Angel of the Lord has spoken!

Gavin,

There's a typo in that example:

@Produces @EJB(ejbLink="../their.jar#PaymentService") 
PaymentService paymentService;

@EJB does not have an element named ejbLink.