EJB3 Hype talk - lookup issue...

[tzablock]

In the EJB3 Trailblazer we can read something like that:

"Loose coupling: Since the client application does not directly instantiate the service objects, it does not need to know the name of the implementation class. It only needs to know the service interface and look up the service stub object from the server using the interface name or a pre-argeed string name. That allows the server to support multiple alternative service implementations without code changes in the client."

That was true when one was using the EJB3 implementation shipped with JBoss 4.0.3 SP server. Lookup was performed on the business interface of the ejb component.

In the RC6 implementation lookup is performed in that manner:

private Calculator cal = null;
public void jspInit () {
try {
InitialContext ctx = new InitialContext();
cal = (Calculator) ctx.lookup(
"EJB3Trail/StatelessCalculator/local");
} catch (Exception e) {
e.printStackTrace ();
}
}

The StatelessCalculator is a bean itself not the business interface. How does it match the "loosely coupled" point of the Trailblazer. Doesn't it violate one of the EJB concepts?

[bdecoste]

The lookup uses the ejbName of the bean. By default, this is the bean classname. If you explicitly specify an alertative ejbName or a jndi binding, the classname is not exposed.

[bill.burke]

Yell at Gavin King if you like the old way [e-mail] and hate the new way. I miss the old way too.

There were some problems with the old way specifically:

1) If you deployed multiple EJBs with the same interface.
2) I fyou deployed a bean class with multiple remote/local interfaces
3) If you deployed multiple versions of the same EJB in different scoped EARs

Bill

[sateh]

There were some problems with the old way specifically:

1) If you deployed multiple EJBs with the same interface.
2) I fyou deployed a bean class with multiple remote/local interfaces
3) If you deployed multiple versions of the same EJB in different scoped EARs

Bill

I think the default naming strategy should reflect the common case. There is always @LocalBinding in case you want to do something different.

Sensible defaults over configuration. In this case the defaults simply don't make sense for most applications.

I scanned the EJB3 JSR for clues but it looks like the naming scheme will be container specific. This is really sad, since it will make it very hard for people trying to integrate EJB3 annotations in existing frameworks.

(For example, I'm working on adding @EJB to Stripes and Wicket and now I have to figure out at runtime in which container the code is deployed in and then use different naming scheme for lookups. Very lame.)

Can I open a JIRA issue for this?

S.

[starksm64]

To avoid being exposed to an implementation detail like the actual global jndi name, you should be using an java ee application client and client side @EJB refs rather than the global jndi lookup.

[sateh]

To avoid being exposed to an implementation detail like the actual global jndi name, you should be using an java ee application client and client side @EJB refs rather than the global jndi lookup.

Scott, that sounds fair. But I'm a bit lost about how that would work technically.

Simple use case: I deploy an .ear with an EJB3 archive and a .war containing a Struts application that needs to reference EJB3s. Struts is the client here. What magic would I have to perform to make @EJB annotations work there then?

Can you give me a hint? I'm not sure how this would work.

S.

[bill.burke]

Yes, you have a great point Stefan. We need some kind of utility so that you can use the injection annotations in plain java objects. There was some talk about this in the Java EE expert group, but it never materialized. Its something we want to implement for JBoss.

I know SEAM has some capability here with its JSF integration.

[sateh]

Yes, you have a great point Stefan. We need some kind of utility so that you can use the injection annotations in plain java objects. There was some talk about this in the Java EE expert group, but it never materialized. Its something we want to implement for JBoss.

I know SEAM has some capability here with its JSF integration.

What can I do to help? The coming 10+ weeks I'll be working on a JBoss/EJB3 project. I can definitely allocate time for this.

Maybe we should move this to the developer forum and define what needs to be done and see how we go from there.

S.

[starksm64]

"Stefan Arentz" wrote:

Scott, that sounds fair. But I'm a bit lost about how that would work technically.

Simple use case: I deploy an .ear with an EJB3 archive and a .war containing a Struts application that needs to reference EJB3s. Struts is the client here. What magic would I have to perform to make @EJB annotations work there then?

Can you give me a hint? I'm not sure how this would work.

S.

You would need to use an ejb-ref in the web.xml. We still don't have support for reference injection on web components. Any pojo within the context of the war that declared the ejb-ref could use the enterprise naming form of the ejb lookup:

<web-app>
 <ejb-ref>
 <ejb-name>ejb/someEJB</ejb-name>
...
 <ejb-link>path-to-ejb-name</ejb-link>
 </ejb-ref>
</web-app>

...

InitialContext ctx = new InitialContext()
ISomeEJB ejb = (ISomeEJB) ctx.lookup("java:comp/env/ejb/someEJB");

Here the string used with the jndi lookup is not subject to vendor specific defaults as its just a link that the vendor deployer has to resolve.

What Bill suggests would be a way to add annotations on non-javaee components. Its a step further than the servlet 2.5 injection support.