Meera has posted 70 posts at DZone. You can read more from them at their website. View Full User Profile

EJB 3.1 – EJB New and Improved!

12.01.2008
| 69854 views |
  • submit to reddit

The EJB 3.0 specification was a huge improvement from what we were used to in the early versions of EJB. Available as an early draft, EJB 3.1 has many more features and is even easier to use.


Let’s take a brief overview of a few interesting topics being considered in this new and improved version of EJB.

Optional Session Bean Business Interfaces:

Writing enterprise applications using EJB 2.1, EJB 3.0 or Spring always promoted the idea of writing component interfaces.  In many cases, you could do with just a POJO without an interface. This new version of EJB allows you to write Session beans with no interfaces; just like you write your JPA entities and Message Driven beans. So, let’s see an example of how this can be accomplished:

package ejb31.samples.stateless.ws;

import javax.ejb.Stateless;
import javax.jws.WebMethod;
import javax.jws.WebService;

import ejb31.samples.entity.Customer;

@Stateless
@WebService
public class CustomerManager
{

@WebMethod
public Customer getCustomer()
{
Customer customer = new Customer();
customer.setFirstName("FirstName");
customer.setLastName("LastName");
return customer;
}

}


Global JNDI Names:

I remember blogging about the issues I had to face due to the portability issues caused by vendor-specific JNDI names. I had to work around a solution for testing on three different application servers: JBoss, Oracle and GlassFish. Each of these application servers has completely different naming convention for remote interfaces.

The GlassFish AS uses the fully qualified name of the remote business interface as default: 

Object obj = initialContext.lookup("com.os.ent.CustomerManagerRemote");

JBoss on the other hand uses the application (EAR) name, followed by the EJB name and followed by a ‘/remote’ constant.

Object obj = initialContext.lookup("ejb3sampleapp/CustomerManager/remote");

Oracle uses the name specified in the @Stateless annotation.

Object obj = initialContext.lookup("CustomerManager");

In EJB 3.1, the global JNDI names would follow a standard pattern that is portable across all the different application servers: 

java:global[/<application-name>]/<module-name>/<bean-name>#<interface-name>

Singleton Session Beans:

In all the earlier versions of EJB’s, we could use two session bean types: Stateless and Stateful. With EJB 3.1, we have the one which many of us felt a need for from time-to-time called the Singleton. Yes, Singletons are POJOs just like our Session beans, and the container is guaranteed to maintain a single shared instance of this Singleton. These Singletons are thread safe and also transactional. Like all other EJB’s, singletons have all the services such as security, remoting, dependency injection, web services, interceptors and so on.

package ejb31.samples.singleton;

import java.util.ArrayList;
import java.util.Collection;
import java.util.HashMap;
import java.util.Map;

import javax.ejb.Singleton;

@Singleton
public class StateRegistryBean implements StateRegistry {

private final Map<String, String> states = new HashMap<String, String>();


public Collection<String> getStates() {
return new ArrayList<String>(states.values());
}


public void removeState(String state) {
states.remove(state);
}


public void setState(String name, String value) {
states.put(name, value);

}

}

Calendar Based Timer Services:

One of the most important changes in EJB 3.1 is the ability to declaratively create cron-like schedules to trigger EJB methods. All that is needed is to annotate an EJB method with the @Schedule annotation to implement the timer.
For example the following schedule represents "Every Monday at 6:15": @Schedule(minute=”15”, hour=”6”, dayOfWeek=”Mon”) send a weekly newsletter to everyone in the list:

@Stateless
Public class NewsLetterBean
{
@Schedule(minute=”15”, hour=”6”, dayOfWeek=”Mon”)
Public void sendNewsLetter()
{
}
}

 


Asynchronous Session beans:

In many enterprise applications I was involved, asynchronous processing was a must. And the only way to accomplish this was by using Message Driven Beans.  Even though writing MDBs was very trivial, configuring all the necessary server resources like connection factories, topics and queues made it a little bit of a chore, especially since all I needed was an asynchronous method invocation.
With EJB 3.1 these issues are easily solved by a simple annotation placed on the Session Bean: @Asynchronous. Under normal circumstances, a Session bean method call blocks the client for the duration of that call. With this annotation in place, the container returns control to the client and executes the method on a separate thread.
The Session bean method call which is annotated with the @ Asynchronous annotation can return a java.util.Future object that allows the client to retrieve a result value, check for exceptions, or attempt to cancel an in-progress invocation.

EJB Lite:

A vast majority of clients I have worked with recently use EJB applications. Most of them use injection, JPA, stateless session beans and transactions, but not necessarily messaging, remoting or web services. EJB Lite is perfect for such applications. The best part of EJB Lite is that you can write your enterprise application with no XML at all, and knowing a very small number of basic annotations.
The following is a list of features proposed for EJB Lite:
•    Stateless, Stateful, and Singleton session beans
•    Only local EJB interfaces or no interfaces
•    No support for asynchronous invocation
•    Interceptors
•    Declarative and programmatic security
•    Declarative and programmatic transactions
•    No support for Timers and scheduling

Easy packaging:

Even for the simplest web application, EJB 3.0 required that we have the components of the web application in a war file, EJB’s packaged in a jar file, and this war and jar in turn be packaged into an ear and deployed. This is very cumbersome, especially for new-comers to Java EE.
This isn’t the case anymore, all you would need to do is to drop all your EJB’s within the WEB-INF/classes directory and deploy these along with your web application.
If you have an ejb-jar.xml file, which again is optional, it would be placed within the WEB-INF directory just like the web.xml file.

EJB 3.1 Embeddable Container:

Testing EJBs was a herculean task all these years. It isn’t anymore with the timely and useful innovation of the embeddable container. The embeddable container allows you to use JPA and EJB 3.1 outside a container.  There are already a number of open source embeddable EJB 3 containers that can run in any Java SE environment. To name a few: Open EJB, GlassFish, JBoss. For unit testing as well as running all the examples included in this article, I used Apache OpenEJB communities latest release of OpenEJB 3.1. OpenEJB is an embeddable, lightweight EJB 3.0 implementation with partial support of EJB 3.1.
Let’s take a look at how I was able to successfully test my Singleton Beans. The listing below shows the test class.

 

package org.ejb31.samples;

import java.util.Properties;

import javax.naming.Context;
import javax.naming.InitialContext;

import junit.framework.Assert;

import org.junit.Test;

import ejb31.samples.singleton.StateRegistry;

public class StateRegistryTest {

	@Test
	public void testStates() throws Exception {
		Properties props = new Properties();
		props.setProperty(Context.INITIAL_CONTEXT_FACTORY,
				"org.apache.openejb.client.LocalInitialContextFactory");

		InitialContext context = new InitialContext(props);

		StateRegistry stateOne = (StateRegistry) context
				.lookup("StateRegistryBeanLocal");

		StateRegistry stateTwo = (StateRegistry) context
				.lookup("StateRegistryBeanLocal");

		stateOne.setState("MaryLand", "MD");
		stateTwo.setState("Virginia", "VA");
		Assert.assertEquals(2, stateTwo.getStates().size());
		Assert.assertEquals(stateTwo.getState("MaryLand"), "MD");
		Assert.assertEquals(stateOne.getState("Virginia"), "VA");


	}

}

In the above test class, the org.openejb.client.LocalInitialContextFactory used as the JNDI provider, will automatically embed OpenEJB into the testing VM. The same instance of OpenEJB is used for all the tests within that VM.

And below is the output from within the Eclipse IDE when you run the above test:

Apache OpenEJB 3.1    build: 20081009-03:31
http://openejb.apache.org/
INFO - openejb.home = C:\dev\ejb3.1\samples
INFO - openejb.base = C:\dev\ejb3.1\samples
INFO - Configuring Service(id=Default Security Service, type=SecurityService, provider-id=Default Security Service)
INFO - Configuring Service(id=Default Transaction Manager, type=TransactionManager, provider-id=Default Transaction Manager)
INFO - Found EjbModule in classpath: C:\dev\ejb3.1\samples\build
INFO - Beginning load: C:\dev\ejb3.1\samples\build
INFO - Configuring enterprise application: classpath.ear
INFO - Configuring Service(id=Default Singleton Container, type=Container, provider-id=Default Singleton Container)
INFO - Auto-creating a container for bean StateRegistryBean: Container(type=SINGLETON, id=Default Singleton Container)
INFO - Configuring Service(id=Default Stateless Container, type=Container, provider-id=Default Stateless Container)
INFO - Auto-creating a container for bean HelloBean: Container(type=STATELESS, id=Default Stateless Container)

INFO - Configuring PersistenceUnit(name=DemoPU)
INFO - Configuring Service(id=Default JDBC Database, type=Resource, provider-id=Default JDBC Database)
INFO - Auto-creating a Resource with id 'Default JDBC Database' of type 'DataSource for 'DemoPU'.
INFO - Configuring Service(id=Default Unmanaged JDBC Database, type=Resource, provider-id=Default Unmanaged JDBC Database)
INFO - Auto-creating a Resource with id 'Default Unmanaged JDBC Database' of type 'DataSource for 'DemoPU'.
INFO - Adjusting DemoPU <jta-data-source> to 'Default JDBC Database'
INFO - Adjusting DemoPU <non-jta-data-source> to 'Default Unmanaged JDBC Database'
INFO - Enterprise application "classpath.ear" loaded.
INFO - Assembling app: classpath.ear
INFO - PersistenceUnit(name=DemoPU, provider=org.apache.openjpa.persistence.PersistenceProviderImpl)
ERROR - JAVA AGENT NOT INSTALLED. The JPA Persistence Provider requested installation of a
ClassFileTransformer which requires a JavaAgent.  See http://openejb.apache.org/3.0/javaagent.html
INFO - Jndi(name=StateRegistryBeanLocal) --> Ejb(deployment-id=StateRegistryBean)
INFO - Jndi(name=HelloBeanRemote) --> Ejb(deployment-id=HelloBean)
INFO - Created Ejb(deployment-id=HelloBean, ejb-name=HelloBean, container=Default Stateless Container)
INFO - Created Ejb(deployment-id=CustomerManager, ejb-name=CustomerManager, container=Default Stateless Container)
INFO - Created Ejb(deployment-id=StateRegistryBean, ejb-name=StateRegistryBean, container=Default Singleton Container)
INFO - Deployed Application(path=classpath.ear)

I haven't seen anything as easier than this to run tests against EJB's. 

Conclusion:

I, like most developers, dreaded working with EJB 2.x. EJB 3 was a big step in the right direction. I myself was involved in writing a couple of enterprise applications in EJB 3.0, which I greatly enjoyed. With this latest, not yet released EJB 3.1 version, it took me less than an hour to explore all the examples shown in this article. I used OpenEJB 3.1 for this article and was even able to test some of the examples as shown above.


What are your thoughts about this upcoming version of EJB? Have you tried using EJB 3.1? The expert group in my opinion has done a tremendous job, what do you think?

You can also send your feedback directly to the expert group at jsr-318-comments@jcp.org. In case you like to know more about EJB 3.1, you can take a look at the EJB 3.1 public draft.
 

 

Published at DZone with permission of its author, Meera Subbarao.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

Meera Subbarao replied on Tue, 2008/12/02 - 8:05am in response to: David Sills

[quote=davidsills]

Meera:

As to the discussions about EJB vs. Spring, why does it have to be versus? I use both, even in the same project; each has its uses and downsides. There is no perfect software.

[/quote]

Yes, indeed David. I wrote another article here a couple of months back about "EJB 3.0 and Spring 2.5".  Even that article had several comments as this one. Yet, I don't understand the versus argument. Why not take the best of both worlds? 

Meera Subbarao

Ryan Developer replied on Tue, 2008/12/02 - 9:29am in response to: Bhaskar Karambelkar

[quote=vkbhaskar2.myopenid.com]

Frankly I don't give 2 cents about industry standards, I think the term is vastly overrated and I have seen so many examples of poor code, just in order to be "standards compliant". So the argument that, JEE specs are "standard  specs" may sell well to management, but won't fly with developer, especialy the ones who have been burned by J2EE.

...

 why should I switch from Spring to web-beans ? What added values do web-beans provide that spring doesn't ?

[/quote]

When SpringSource announced their very own application server that starts at $22,500 per year (even if you just want basic support on only DI) a lot of the Spring community started to express their true feelings about Spring's legacy bloat, and how it has become even more complicated than the specs it was designed to replace.  In fact, it's become a whole application server.  Many Spring users talked about defecting to Guice, checking out EJB 3.1, WebBeans, etc.  There are a lot of dissastisfied Spring developers.   I am one of them, and I can't wait for JEE 6.  There is no reason to use Spring when JEE has everything I need pre-integrated with no XML hell integrating everything.  If Java EE 6 provides _everything_ I need, why should I use Spring?  I want JPA 2.0.  I want WebBeans. I want EJB 3.1.  I want JSF 2.0.  I want JTA.  I want JAX-WS.

 

[quote=vkbhaskar2.myopenid.com] 

No comparison here, Spring + AspectJ is SO SO SO much more powerful than anything the "JEE land" has to offer for AOP.

[/quote]

I wonder how many people really care that AOP lets you do more than EJB interceptor's arround invoke.   The last poll at my JUG showed that most people use Spring, but only for basic DI and hardly anyone uses AOP for anything more than transactions etc. The stuff EJB provides.  

 

[quote=vkbhaskar2.myopenid.com]

EJB 3.1 only supports JPA, while Spring out-of-box supports JPA, Hibernate, iBatis, and good old plain JDBC. This makes it much easier when working with legacy databases.

[/quote]

Who says you can't use JDBC in EJBs?  Who says you can't use Hibernate, or iBatis in EJBs?  Just because there isn't a @PersistenceContext annotation to inject it doesn't mean you can't use these.   And dont' forget WebBeans DI. 

 

[quote=vkbhaskar2.myopenid.com]  

EJB 3.1 can only be injected in servlets, or JSF managed beans, but Spring managed beans can be injected in Servlets, JSF Managed beans, Struts, Webworks, Tapestry, wicket, Spring web flow, 

[/quote]

WRONG.  WebBeans gives JEE 6 that flexibility.

 

[quote=vkbhaskar2.myopenid.com]

not to mention excellent support for various view technologies like JSP/JSTL, Tiles,Velocity, Framemaker, jasper reports etc. To use only EJBs in any of these view technologies/ web frameworks (besides JSF/Seam) is going back to the service locator pattern.

[/quote]

Great, WebBeans will be usable by these view technologies as well.  Plus I'm sure all of the major web frameworks will add support for WebBeans if additional support is required. 

 

[quote=vkbhaskar2.myopenid.com]

But with spring I can bring the full DI feature set in to these MBeans, which is not possible with EJBs. EJBs can only be injected in other EJBs/Servlets remember!

[/quote]

WebBeans. Yes, like Spring's separate .jar files for various parts of functionality, the JEE specs are spearate too but used together. WebBeans + EJB 3.1 = Spring. Use only the parts you need for what you are working on.  You don't need fully transactional and concurrent EJBs for everything.  WebBeans helps in that area. 

Bhaskar Karambelkar replied on Tue, 2008/12/02 - 10:48am in response to:

[quote=rdelaplante]

When SpringSource announced their very own application server that starts at $22,500 per year (even if you just want basic support on only DI) a lot of the Spring community started to express their true feelings about Spring's legacy bloat, and how it has become even more complicated than the specs it was designed to replace.  In fact, it's become a whole application server.  Many Spring users talked about defecting to Guice, checking out EJB 3.1, WebBeans, etc.  There are a lot of dissastisfied Spring developers.   I am one of them, and I can't wait for JEE 6.  There is no reason to use Spring when JEE has everything I need pre-integrated with no XML hell integrating everything.

 [/quote]

Spring framework is not the same as the Spring Application Server. If indeed spring framework becomes closed source at some point of time, lot of people will migrate away from spring, including myself.  But till  that day comes, I am a happy spring camper.

[quote=rdelaplante]

If Java EE 6 provides _everything_ I need, why should I use Spring?  I want JPA 2.0.  I want WebBeans. I want EJB 3.1.  I want JSF 2.0.  I want JTA.  I want JAX-WS.

[/quote]

To each his own I guess. I listed out various stuff that JEE 6 doesn't provide me, so I guess it boils down to requirements for the project.

 [quote=rdelaplante]

I wonder how many people really care that AOP lets you do more than EJB interceptor's arround invoke.   The last poll at my JUG showed that most people use Spring, but only for basic DI and hardly anyone uses AOP for anything more than transactions etc. The stuff EJB provides.  

[/quote]

 Again, to each his own. I am a big fan of AOP and use it for implementing many cross cutting concerns in my projects, not just transactions or DI. 

 [quote=rdelaplante]

Who says you can't use JDBC in EJBs?  Who says you can't use Hibernate, or iBatis in EJBs?  Just because there isn't a @PersistenceContext annotation to inject it doesn't mean you can't use these.   And dont' forget WebBeans DI. 

[/quote]

Nobody says that, it's just that using Spring + (iBaits, JDBC ) is much more easier than EJB + (iBaits . JDBC). Spring has a lot of framework API that makes working with any ORM technology including JPA, and plain old JDBC much easier.

[quote=rdelaplante]

Great, WebBeans will be usable by these view technologies as well.  Plus I'm sure all of the major web frameworks will add support for WebBeans if additional support is required. 

[/quote]

That would be nice. 

 [quote=rdelaplante]

WebBeans. Yes, like Spring's separate .jar files for various parts of functionality, the JEE specs are spearate too but used together. WebBeans + EJB 3.1 = Spring. Use only the parts you need for what you are working on.  You don't need fully transactional and concurrent EJBs for everything.  WebBeans helps in that area. 

[/quote]

 Webbeans sure look interesting.  But my point is Spring is much more than a mere DI framework and even though EJB 3.1 + Webbeans combination has got the DI part well covered, there are still quite a few areas of Application Development that the combo lacks and spring does not.

Again the point of this discussion is not to get personal, but merely try and give the EJB/JEE team a view of why Spring is so popular and help them understand developer requirements. May be not all points I raised can be implemented as Specifications, but at least they can serve as pointers when designing the JEE specs or app. servers based on them.

Ryan Developer replied on Tue, 2008/12/02 - 11:15am in response to: Bhaskar Karambelkar

[quote=vkbhaskar2.myopenid.com]

Spring has a lot of framework API that makes working with any ORM technology including JPA, and plain old JDBC much easier.

...

But my point is Spring is much more than a mere DI framework and even though EJB 3.1 + Webbeans combination has got the DI part well covered, there are still quite a few areas of Application Development that the combo lacks and spring does not.

[/quote] 

I will agree 100% with that.  Most spring vs ejb discussions are exactly that, one or the other.  No Spring users say what you just said.  I think this is what Reza was trying to point out.  Those who choose to use the infrastructure of Java EE instead of the infrastructure of Spring can still benefit from the helper classes available in Spring, including the testing framework. 

That reminds me of something I wanted to say.  EJB 3.0 and EJB 3.1 can be used in desktop apps and unit tests like Spring using containers like OpenEJB. EJB 3.1 has spec defined features to standardize running the container outside of an application server. I'm pretty sure I read that WebBeans is also being done in a way that can be used outside of an application server.

 

[quote=vkbhaskar2.myopenid.com]

Again the point of this discussion is not to get personal, but merely try and give the EJB/JEE team a view of why Spring is so popular and help them understand developer requirements. May be not all points I raised can be implemented as Specifications, but at least they can serve as pointers when designing the JEE specs or app. servers based on them.

[/quote]

Yes I don't think the helper/utility classes in Spring will be turned into specs.   Other than the lack of pointcuts in WebBeans interceptors and EJB 3.1 interceptors I think the infrastructure is sound.   Once Spring becomes a WebBeans and EJB 3.1 implementation, then the Java EE community will be able to benefit from the non-infrastructure utility features of Spring, hopefully in a way that doesn't impose the Spring infrastructure the way WebFlow requires Spring MVC. 

Reza Rahman replied on Tue, 2008/12/02 - 4:25pm in response to: Bhaskar Karambelkar

Bhaskar,

Firstly, congratulations on writing a long post. Whatever the merits of what you say, it is always good to see genuine passion.

The biggest problem is that what you are proudly touting as "advantages" are actually making Spring far more complex, heavyweight and bloated compared to Java EE APIs. I see this everyday in talking with Java EE 5 developers (with or without Seam) that find their work a lot more agile, learning curves far smoother and configuraton much simpler, all with not much useful feature loss. Here are a few observation points as someone working with Spring for a good few years:

AOP: This is a blatant point of bloat and complexity for Spring. Two highly redundant approaches, both takes a rocket scientist to apply. For your own benefit, take a quick look at what WebBeans interceptors and decorators offer. They do the same thing without the bottles of aspirin :-).

Scheduling: All I've ever seen used is Quatrz, and even that's pretty complex. JDK timers and task executors are pure bloat.

Remoting: RMI and web services (REST and SOAP) are more than sufficient to cover almost all use-cases. Burlap, Hessian HTTP invokers can easily be done without.

JPA, Hibernate, iBatis: Again, the DAO support stuff does very little on top of what these technologies natively support in terms of Java EE integration, even the iBATIS tool that probably sees the lowest frequency of use.

JMSTemplate, JDBCTemplate: Actually useful APIs that are easily integrated with EJB.

Given the above, you'll excuse me if I don't take your post too seriously. I think Java EE is much better off focusing on fundamentals, much like Ruby on Rails.

Regards,

Reza

P.S.: I am deliberately ignoring the "intolerant Java EE" remark. I think the discussion here alone proves quite the opposite is true. Let's please not resort to this, it will take us nowhere.

Per Olesen replied on Tue, 2008/12/02 - 4:58pm in response to: Reza Rahman

Reza,

You seem like you are on a personal vendetta to tell the world, that spring is bloated crap and JEE will save the world. Maybe you are not, but it looks that way.

...AOP: This is a blatant point of bloat and complexity for Spring...

... Scheduling: All I've ever seen used is Quatrz, and even that's pretty complex. JDK timers and task executors are pure bloat...

... Burlap, Hessian HTTP invokers can easily be done without...

Just because you haven't seen the use of the above, others might. I know I do. I use JDK timers and task executors. I use the AOP in spring, does that then make me a rocket scientist?

Please recoqnize, that other people might be using the best tool for the problem at hand. If this includes task executors, Hessian or Burlap, then so be it.

I could now quote you: "Given the above, you'll excuse me if I don't take your post too seriously".

Reza Rahman replied on Tue, 2008/12/02 - 5:20pm in response to: Per Olesen

Per,

[quote=pulesen]you are on a personal vendetta[/quote]

I think you are crossing the line here a little bit. Above all, I take pride in professional objectivity as an independent consultant. There is nothing personal here. Let's not get personal just because you might not like what we have to say...

[quote=pulesen]Just because you haven't seen the use of the above, others might.[/quote]

As I said, these are observations based on years of personal experience with a variety of team-based projects and having talked to a large variety of people. It's possible your experience is different, but it is rather improbable that it applies generally, particularly since I've had to document my choices based on sound technical reasons that these APIs are just not all that useful. And the comment on AOP is something I've seen first hand and heard numerous times, particularly vis-a-vis interceptors and decorators in Java EE.

Regards,

Reza

Kenneth Mark replied on Wed, 2008/12/03 - 1:10pm

Really exciting ( or many times eager ) for those new features.

Hope they will be ready soon.

Meera Subbarao replied on Wed, 2008/12/03 - 1:26pm

I really liked all these features in this upcoming version. I am eager to use them in a real world project.

Reza Rahman replied on Wed, 2008/12/03 - 2:36pm in response to: Meera Subbarao

Meera/Kenneth,

Glad to hear it. As you mentioned in the article, the OpenEJB team is very far along already. The GlassFish team also seems like they would like to have a beta release around JavaOne next year.

Until that point, everyone in the EG is hoping to hear any and all constructive feedback. In my opinion, that's the only way to develop a quality specification. That applies to all the Java EE 6 specs, not just EJB 3.1.

Regards,

Reza

Meera Subbarao replied on Wed, 2008/12/03 - 2:54pm

Reza,

It was really easy to download, install and use OpenEJB. They mostly has Maven scripts, not a big fan there, so spent less than an hour writing Ant scripts for compiling, testing and deploying. Once I got those working, it was so easy to continue.

On a different note, if you and your co-authors are planning on writing "EJB 3.1 in Action", what would you compare this version of EJB's with?

My guess would be an Ant or Bee.

Ryan Developer replied on Wed, 2008/12/03 - 3:08pm in response to: Reza Rahman

[quote=rrahman]

The GlassFish team also seems like they would like to have a beta release around JavaOne next year.

[/quote]

Oh no!  I thought the spec would be final by JavaOne 2009 and GlassFish V3 support for EE 6 would go final almost immediately after.  Hopefully it won't take months to get released. 

The spec final drafts are supposed to be done many months before JavaOne 2009, right?

Reza Rahman replied on Wed, 2008/12/03 - 3:18pm in response to: Meera Subbarao

Meera,

[quote=meera]if you and your co-authors are planning on writing "EJB 3.1 in Action", what would you compare this version of EJB's with?[/quote]

We are planning the second edition right now. In reference to our opening analogy, we'll still stick with the venerable cow...

As such 3.1 isn't a big release and is just the stuff that could not fit into the 3.0 schedule really. WebBeans is really where the "action" is this time. Maybe you should consider writing an article on that? I know Gavin wants feedback...

Regards,

Reza

P.S.: Know what you mean about Maven. I'm not a "fan" either...

Reza Rahman replied on Wed, 2008/12/03 - 3:21pm in response to:

Ryan,

[quote=rdelaplante]The spec final drafts are supposed to be done many months before JavaOne 2009[/quote]

Doesn't look that way right now. There's just too much to do and hurried specs are a bad idea given the number of people it effects...

Cheers,

Reza

Meera Subbarao replied on Wed, 2008/12/03 - 3:51pm in response to: Reza Rahman

[quote=rrahman]

WebBeans is really where the "action" is this time. Maybe you should consider writing an article on that? I know Gavin wants feedback...

[/quote]

I haven't even looked at WebBeans. With 2008 coming to an end, it is time to set goals for 2009, so this might be one in the list.

Thanks Reza.

Meera Subbarao

Roman Pichlik replied on Wed, 2008/12/03 - 4:51pm

Reza please try to explain me how i will able to do the following with EJB 3.1

with Spring I can do DI via setter method, variable name, constructor argument , also managed beans can be instanciated using constructors, factories, static methods, JNDI look ups.

Becaus this is exactly what developers need (i 've seen it a couple of times). There are regular cases where is necessary to delegate instantion of an object from the IoC container to some kind of factory or factory method for instance - this is only one example what Spring IoC container offers. We can take its capabilites feature by feature and try to compare with EJB 3.1 IoC container . EJB 3.1 missed (again) the key point of 'framework non-invasivity'. The DI capabilities are proof of that.

Ryan Developer replied on Wed, 2008/12/03 - 5:31pm in response to: Roman Pichlik

[quote=rp117107]Reza please try to explain me how i will able to do the following with EJB 3.1

with Spring I can do DI via setter method, variable name, constructor argument , also managed beans can be instanciated using constructors, factories, static methods, JNDI look ups.

Becaus this is exactly what developers need (i 've seen it a couple of times). There are regular cases where is necessary to delegate instantion of an object from the IoC container to some kind of factory or factory method for instance - this is only one example what Spring IoC container offers. We can take its capabilites feature by feature and try to compare with EJB 3.1 IoC container . EJB 3.1 missed (again) the key point of 'framework non-invasivity'. The DI capabilities are proof of that.

[/quote]

WebBeans solves exactly that problem. The Java EE 6 expert group didn't miss any key points. They have paid close attention to the industry and hit the nail square on the head.  Like JPA was removed from the EJB spec into a separate JSR, next-generation full featured DI capabilities are now being developed in a separate JSR too.  Like JPA, WebBeans works with or without EJB. 

It would help if you could give concrete specific examples (code and configuration) of what you think Spring does that WebBeans + EJB 3.1 together can't. 

Reza Rahman replied on Wed, 2008/12/03 - 6:26pm in response to: Roman Pichlik

Roman,

EJB 3.0 today supports setter injection, field injection, constructor instantiation and lookups. That leaves  constructor injection and factory/static methods. As I see it, these are at best edge cases since the 50+ Spring systems I have seen first hand don't even use them and the world has not ended for them :-).

So I beg to differ on the assertion that "this is what the community wants". I think it's more the case that this is what SpringSource is touting as their competetive advantages to meet their own goals and some people are just taking their messages for granted. I do think in this case the "emperor is naked" and a majority of people are just too afraid to speak up (but are just starting to), not even about the obvious bloat, complexity and vendor lock-in problems in Spring. However, I can't say I'm surprised. It ook people 5+ year to figure out EJB 2.x was crap.

That all being said, as Ryan mentions, all of this can be done via  WebBeans and looks like there is a good chance EJB 3.1 will be adding consructor injection too.

Regards,

Reza

Roman Pichlik replied on Thu, 2008/12/04 - 4:42am in response to:

WebBeans solves exactly that problem.

Correct me if i'm wrong, but WebBeans fills the gap between component model of business layer and component model of web layer. You can easilly use a EJB bean in JSF and vice versa, but what i'm talking about is using of DI as model for coupling of business logic without any dependency to web layer e.g. servlet context. I agree there must be the dedicated spec only for DI at least for Java EE or oven better for Java SE.

There is one nice example as demonstration of powerfull DI. I'm calling it "dynamic collecting of implementation"


public interface ServiceProvider {
}

@Service
public class MyProviderA implements ServiceProvider {
}

@Service
public class MyProviderA implements ServiceProvider {
}

@Service
public class ServiceProviderRegistry {
   @Autowired
   private List providers   

} 

@RunWith(SpringJUnit4ClassRunner.class)
@ContextConfiguration(locations={"classpath*:META-INF/applicationContext.xml"})
public class ServiceProviderRegistryTest {
    @Autowired
    private ServiceProviderRegistry registry;

    @Test
    public void test() {
        assertThat(registry.getProviders().size(), is(2));
    }
}

This code shows you, how dynamically introduce a new implementation without tightly coupling between provider and consumer and it is absolutelly must if you are going to provide some extension points in your API. So no show me how to do it in WebBeans and how difficult will be write a test for it.

Bhaskar Karambelkar replied on Thu, 2008/12/04 - 5:07am in response to: Roman Pichlik

A piece of advice , be prepared for answers like "If it's good enough for me, then it ought to be good enough for every one". Also be prepared for accusations of taking the discussion "personally", when all your post does, is give concrete examples of what you as a developer desire.

Also be prepared for those extremely clever sarcastic back handed comments , that are meant to tell you how you don't have a clue about what JEE programming is all about. :-).

 And for goodness sake don't even utter the word "Spring Framework", because you know it is bloated, and you have to write SO much xml and SO many developers hate it, and it's only the springsource people who are touting it ;).

 You have been warned.

Reza Rahman replied on Thu, 2008/12/04 - 10:11am in response to: Bhaskar Karambelkar

Bhasker,

I must be having a nighmare or something...are you actually threatening me becuase I disagree with you? Really think this kind of attitude helps anyone or makes anyone pay attention to you? Indeed, this is exactly the attitude I refer to when I talk about the "emperor is naked" story. Let's be more civil please :-).

I hope it's enough to say that my observations are hardly my own and are easily provable via simple data gathering. I do dare say my "sample size" is pretty representative. For one, I haven't heard a single solid technical argument as to why the features I think are bloat are "necessary" for a majority of applications?

I think I should accept the challenge and write an article or two about what I observe :-).

Regards,

Reza

Reza Rahman replied on Thu, 2008/12/04 - 10:18am in response to: Roman Pichlik

Roman,

If you really want, we can belabor this discussion further. If I may ask you to respect my time, I assure you what you have posted is possible today in EJB 3.0 (I've done it numerous times myself) and is most certainly possible in WebBeans/EJB 3.1.

That being said, do let me know if you need further details. I do ask that we keep this professional and not let things devolve to a pointless shouting match that only an internmet troll can love...

Regards,

Reza

Per Olesen replied on Thu, 2008/12/04 - 12:48pm in response to: Reza Rahman

Hi Reza,

Roman has been kind enough to take his time to provide an example, that he would like to see how can be done in EJBs. Given the discussion in this threat, it would be fair if you showed us how this is done in an EJB based example.

Martijn Verburg replied on Thu, 2008/12/04 - 1:21pm in response to: Per Olesen

[quote=pulesen]Hi Reza,

Roman has been kind enough to take his time to provide an example, that he would like to see how can be done in EJBs. Given the discussion in this threat, it would be fair if you showed us how this is done in an EJB based example.[/quote]

 Yes please!  I'm pretty much framework agnostic, but I have been impressed by Spring's flexibility (I workl on strange JCA connector based messaging architecture) .  I'm definitely interested to see JEE6/Web Beans examples to compare (we're looking at moving our old EJB 2.1 beans to either Spring POJOs or EJB 3.0/3.1 beans sometime in the future, at this stage we're still leaning towards Spring).

 Cheers,

Martijn

Reza Rahman replied on Thu, 2008/12/04 - 2:00pm in response to: Martijn Verburg

Martijn,

[quote=karianna]Yes please![/quote]

OK, I'll be glad to help here - with one request as professional courtesy to me and others.

Let's take this discussion to a separate thread somewhere. As I see it, this has turned *way* off-topic into a EJB 3.1 vs. Spring or WebBeans vs. Spring debate as opposed to discussing features in EJB 3.1. From one perspective, it hijacks attention away from people who could really benefit from discussions around the article. It doesn't have to be on DZone. Any "ideologically neutral" forum is fine so I can freely speak my mind as much as that is possible. That being said, I think such a discussion/debate/comparison is only a matter of time, I just don't think this is the right time and place.

In the least, I would like to hear from Meera since she is a Zone leader before encouraging this line of discussion further. For one, I do wish to be a "good citizen" of JavaLobby.

Thanks in advance,

Reza

Per Olesen replied on Thu, 2008/12/04 - 2:25pm in response to: Reza Rahman

Hi Reza,

Let's take this discussion to a separate thread somewhere. As I see it, this has turned *way* off-topic into a EJB 3.1 vs. Spring or WebBeans vs. Spring debate as opposed to discussing features in EJB 3.1. From one perspective, it hijacks attention away from people who could really benefit from discussions around the article

I think it is fine to keep it here. And I am perfectly sure, that dzone are fine with it here. After all, this is what the site is for.

I agree, that we are a bit off topic. On the other hand, comparing EJB3.x and spring is important, and helpful for many, as EJBs and spring are competing in the market. And not all developers are clear on their differences and cons and pros. Martijn has just expressed a concrete wish to see the example shown in EJB world.

We have gathered some people here already, that have found interest in the topic. Let's keep it here.

As much as it might look like I hate EJBs, I actually do not. I think there is a place for EJB3.x. But I also think it is important to know its limits. Just as it is important to know the cons of spring too.

I look forward to seeing the spring example given by Roman expressed in EJB world and I hope we can keep it here, where we are already gathered.

Meera Subbarao replied on Thu, 2008/12/04 - 5:48pm in response to: Reza Rahman

[quote=rrahman]

In the least, I would like to hear from Meera since she is a Zone leader before encouraging this line of discussion further. For one, I do wish to be a "good citizen" of JavaLobby.

[/quote]

As long as it is a healthy discussion on Spring Vs EJB and not a war of words between two individuals, I have no problem at all.

Meera Subbarao

Roman Pichlik replied on Thu, 2008/12/04 - 5:51pm in response to: Reza Rahman

Reza, first of all, thank you for your time. Should i create a separate post on DZone? I'm convinced of this post is exactly right place and people here are right audience.

Reza Rahman replied on Thu, 2008/12/04 - 6:32pm in response to: Roman Pichlik

Roman,

Sadly, I am not convinced of either and would indeed like a separate thread if we continue this at all. Not sure what the title should be exactly, whatever you think would be appropriate and non-deceptive. To a degree, this goes back to what question you are really trying to accomplish in the first place.

I know that my reply would have little to do with EJB 3.1 per se. Are you sure you can't seek out these answers yourself? I've felt I have provided enough material for further independent research and this is unlikely to be much more than a shouting match of the same old, tired arguments by the same old, tired people that do more talking than listening. And it would waste a lot of my time and energy when the answers are really already "out there" for anyone honestly seeking...

Quite fankly, the tonality of some of the participants does not convince me this is an appropriate thread anywhere at this point. That's why I'd like to hear from someone like Meera before I do anything else on this. I know her personally and value her judgement anyways.

Regards,

Reza

Reza Rahman replied on Thu, 2008/12/04 - 6:43pm in response to: Roman Pichlik

Roman,

Just to make sure, if you do create a new thread, do try to keep the code you posted the same. I don't want to be chasing a constantly moving target..helps in keeping the scope of the discussion manageable.

It is OK to change the code right now, though.

Thanks,

Reza

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.