[jboss-user] [EJB3] - The on-going story of hot-deploying EJBs

[Carlo de Wolf]

Carlo de Wolf [http://community.jboss.org/people/wolfc] modified the blog post:

"The on-going story of hot-deploying EJBs"

To view the blog post, visit: http://community.jboss.org/community/ejb3/blog/2011/02/23/the-on-going-story-of-hot-deploying-ejbs

--------------------------------------------------------------
Frequently I get questions and remarks on hot-deploying EJBs for RAD ( https://issues.jboss.org/browse/EJBTHREE-1096 EJBTHREE-1096).  “Can we hot-deploy EJBs?” “Have you forgotten your most popular issue?”

The thing is that it's not as simple as it looks. Even just hot-deploying the bean class itself runs into issues. You could have an instance in such a state that violates the new invariants of the class.

Suppose we would change
void setName(String s) {
    this.name = s;
}

into
void setName(String s) {
    if(s == null) throw new IllegalArgumentException();
    this.name = s;
}

We could have instances where the name field is actually null.

But we want more than just class hot-deploy. That is something you can do with the JDK already. We also want to be able to change the views of an EJB. At that point you run into trouble with existing consumers of the views. How are they supposed to react? Does a Servlet need to re-lookup the proxy? How would it react to non-existing methods?
One of the worst things to do (in my book) is modifying the Servlet with the knowledge that the EJB might be hot-deployable. In other words let plumbing code creep into your business code.

To ensure code correctness hot-deploying EJBs should never be enabled in production. We don't want unneeded complexity there. So I would not consider it an assignment for a product engineer.

Alternatively you could use  http://www.zeroturnaround.com/jrebel/ JRebel. Granted I've never used it, so I am ignorant of how they solve the problem. But if JRebel fits your purpose then you should is it.

Still I don't see it as a reason to reject the issue. If the problem is solvable without an increase in complexity I would accept such a solution.

But what I really would like to have is a rolling upgrade. You install a new version EJB which from that point on gets used by new clients. This would be beneficiary to both the community edition and the product. In essence it comes back to the same problem: how do we deal with established connections to, for example, Servlets? So a solution giving rolling upgrade would have to span technologies and be solved at the server level.

Now with the inception of  http://community.jboss.org/docs/DOC-15596 JBoss Application Server 7 we are rebuilding a new scaffold on the knowledge we've acquired over years. I think this is a great opportunity to see if we can find a solution to EJBTHREE-1096 that would fit in AS 7.

So I'm looking forward to ideas and contributions on AS 7 that would meliorate EJBTHREE-1096.

Is the issue stalled, yes. Is the issue forgotten, no.

[1]  https://issues.jboss.org/browse/EJBTHREE-1096 https://issues.jboss.org/browse/EJBTHREE-1096
[2]  http://community.jboss.org/docs/DOC-15596 http://community.jboss.org/wiki/HackingonAS7
--------------------------------------------------------------

Comment by going to Community
[http://community.jboss.org/community/ejb3/blog/2011/02/23/the-on-going-story-of-hot-deploying-ejbs]

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jboss-user/attachments/20110223/0a5129a7/attachment-0001.html