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).

@EJBis 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...

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?

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,

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. :-(

well of course, what do you expect from someone who uses "bah humbug"? The Angel of the Lord has manifested itself again as a horse. Nobody uses Weld, nobody used Seam, nobody will use Ceylon. Let him say whatever he wants, he lives in a sorry world of denial and isolation. equate.