Hi Andrew, I think your current plan sounds fine.
I don't think Geronimo has implemented EJB 3 support yet. I have heard that JBoss claims to have support for EBJ 3, but haven't really looked at it yet to see how complete it is. The EJB control's DRTs do use Geronimo, so there may be a bit of work necessary to get them up an running with some other application server. Try to keep the dev list updated with the results of your investigation, right now I think a lot of devs are still spinning up on the EJB 3.0 spec so you may not get lots of feedback at least initially. - Chad On 7/14/06, Andrew McCulloch <[EMAIL PROTECTED]> wrote:
I have been reading up a bit on the EJB 3 spec and I would like to look into updating / cloning the current EJBControl to support the EJB 3.0 client contracts. I am looking for a few pointers on what features of the new spec the community might be most interested in (it may be too new for this feedback). I would also be receptive to any other thoughts on this topic that you may have. My current plan: 1. Determine if the current controls works against EJB 3 beans that use the back-compat annotations in the spec to produce the remote interfaces and other EJB 2.1 artifacts. 2. Determine what would have to be modified on the Session Bean Control to use only the Business interface through direct lookups. 3. Determine what would have to be modified on the Entity Bean Control to use only EJB 3.0 artifacts through direct lookups. 4. Determine what would have to be modified on the 2 controls to make use of EJB Dependency Injection instead of direct lookups. 5. Prototype a new Session Bean Control 6. Prototype a new Entity Bean Control ... I am not as familiar with the persistence portion of the as with the portion defining the Session and Message-Driven interfaces so I am not sure the scope of changes that may be required around the Entity Bean Control and EJB-QL changes specifically. Also, I am not sure as to the current Geronimo support for EJB 3. I believe this is where the current EJBControl drts run, if that support is unavailable I may have to test against another container.
