Re: [openejb-dev] Re: Cut date for 1.1?
On Jan 22, 2006, at 5:58 PM, David Jencks wrote: On Jan 20, 2006, at 1:33 PM, Dain Sundstrom wrote: I am working on splitting the OpenEJB container into one object for each deployed ejb and a set of share invocation processing ejb containers. This is a refactoring of internal interfaces well below the layer our users see. Does this mean there will be one interceptor stack for each ejb type, shared among all the e.g. stateless sesssion ejbs? By default, yes. The idea is you can deploy extra invocation processors that have different QoSes configured and then you assign an ejb to the processor you want. What is the advantage of this design? I think the important important advantage for OpenEJB is that this change aligns the 2 code with the 1 code. The other big advantage is that it the job of a deployer is simpler because the most complex configurations (like caches) are placed on the invocation processors which will be defined using he generic gbean xml tags. I can think of some disadvantages compared to our present design but no advantages. Probably just a lack of imagination, but I'd really appreciate discussion of architectural changes before the code arrives. The architectural change is to split the current EJB container into a service for each EJB and a shared service for invocation processing. If you want to have a discussion on this, we should move to the openejb dev mailing list. I thought about this several years ago in reference to another app server and thought of 2 designs. I'm curious if you picked one or found a third, and your reasons. I'll describe the designs in terms of gbeans for simplicity. 1. The gbeans themselves form the interceptor stack. This means the ejb gbean needs to have an ejb context object that it sends down the stack with each call containing the info particular to that ejb, such as the transaction policy settings. Since you don't really have any idea what interceptors are present, AFAICT you either need to code generate a context object to suit the particular interceptors present, or use a map. A map is a bit slow and loses type safety, whereas code generation seems awfully complicated. I suppose it might be possible to use an Object[] and figure out the indices for each interceptor when the ejb starts. 2. The gbeans are interceptor factories, and when the ejb starts it uses the factories to construct its own personalized interceptor stack. Here, each interceptor instance can hold the context information for itself, and initializing it from a map does not have a performance penalty. On the other hand, you get more interceptor object instances. Dain's on the road again, but I have seen some of the code and try and recall what I can. From the choices, I'd say it's closer to 1 than 2. I distinctly remember a very impressive looking map implementation that was type safe in it's understanding of methods. IIRC it was an object array, not a true map, that gave you method - object indexing ability. Something of that nature. The motivation is something I can speak a little more about as it's basically a lot of design concepts we found useful in the past. I think he just got sick of hearing me talk about it and decided to give it a try :) The idea being to split the ejb specific stuff from the stuff that is not entirely ejb specific, but likely more specific to beans of that type. So things like pool settings, or caching settings could just be configured generally and not over and over again on a per-ejb basis. You can do more at a macroscopic level and are forced to do less at a microscopic level. The bean type information goes to the container (which could be implemented as a stack of interceptors) and the bean specific information goes into the ejb context object. For people who know OpenEJB 1, that would be DeploymentInfo (bad name) and Container. Surprisingly, it cleans up your code quite a bit to separate concerns at that level and allows you some great config options. Say for example, you could tweak the pool size for all the stateless session beans running in a given container via a management console. No need to grab each bean individually and set it's pool size. It also allows you to easily leverage new container implementations. For example, when we ran the ejb test suite at ApacheCon 2003 that was basically the nova containers wrapped with an adapter and used in an unmodified OpenEJB 0.9.2 distribution. Adhering to the idea that simple things should be simple and complex things possible, if you did want to be very specific and microscopic in the management of a particular ejb, you just dedicate a new container definition to that ejb (i.e. a container with one ejb). An easy way to do that would be via another gbean declaration which you could probably put right in the openejb-jar.xml
Re: Cut date for 1.1?
I'd prefer to copy the Geronimo list if the discussion moves. FWIW I think a lot of folk that are on the G list would be interested. Since OpenEJB is making the move to Geronimo (assuming it happens) I think it would be good to keep the thread on this list so the history is cohesive. Dain Sundstrom wrote: This is really a discussion for the openejb mailing list, but since you asked here I'll respond here. On Jan 20, 2006, at 11:17 AM, David Jencks wrote: On Jan 20, 2006, at 9:59 AM, Dain Sundstrom wrote: On Jan 20, 2006, at 9:46 AM, David Jencks wrote: Personally I am not ready for 1.1 to be frozen. Also, there is at least one major bug (tomcat cross-context dispatch) that needs to be fixed and I haven't seen any progress on it. The nature of your change might affect other peoples opinion on this also, what are you planning? I am working on splitting the OpenEJB container into one object for each deployed ejb and a set of share invocation processing ejb containers. This is a refactoring of internal interfaces well below the layer our users see. Does this mean there will be one interceptor stack for each ejb type, shared among all the e.g. stateless sesssion ejbs? By default, yes. The idea is you can deploy extra invocation processors that have different QoSes configured and then you assign an ejb to the processor you want. What is the advantage of this design? I think the important important advantage for OpenEJB is that this change aligns the 2 code with the 1 code. The other big advantage is that it the job of a deployer is simpler because the most complex configurations (like caches) are placed on the invocation processors which will be defined using he generic gbean xml tags. I can think of some disadvantages compared to our present design but no advantages. Probably just a lack of imagination, but I'd really appreciate discussion of architectural changes before the code arrives. The architectural change is to split the current EJB container into a service for each EJB and a shared service for invocation processing. If you want to have a discussion on this, we should move to the openejb dev mailing list. -dain
Re: Cut date for 1.1?
On Jan 20, 2006, at 1:33 PM, Dain Sundstrom wrote: This is really a discussion for the openejb mailing list, but since you asked here I'll respond here. On Jan 20, 2006, at 11:17 AM, David Jencks wrote: On Jan 20, 2006, at 9:59 AM, Dain Sundstrom wrote: On Jan 20, 2006, at 9:46 AM, David Jencks wrote: Personally I am not ready for 1.1 to be frozen. Also, there is at least one major bug (tomcat cross-context dispatch) that needs to be fixed and I haven't seen any progress on it. The nature of your change might affect other peoples opinion on this also, what are you planning? I am working on splitting the OpenEJB container into one object for each deployed ejb and a set of share invocation processing ejb containers. This is a refactoring of internal interfaces well below the layer our users see. Does this mean there will be one interceptor stack for each ejb type, shared among all the e.g. stateless sesssion ejbs? By default, yes. The idea is you can deploy extra invocation processors that have different QoSes configured and then you assign an ejb to the processor you want. What is the advantage of this design? I think the important important advantage for OpenEJB is that this change aligns the 2 code with the 1 code. The other big advantage is that it the job of a deployer is simpler because the most complex configurations (like caches) are placed on the invocation processors which will be defined using he generic gbean xml tags. I can think of some disadvantages compared to our present design but no advantages. Probably just a lack of imagination, but I'd really appreciate discussion of architectural changes before the code arrives. The architectural change is to split the current EJB container into a service for each EJB and a shared service for invocation processing. If you want to have a discussion on this, we should move to the openejb dev mailing list. I thought about this several years ago in reference to another app server and thought of 2 designs. I'm curious if you picked one or found a third, and your reasons. I'll describe the designs in terms of gbeans for simplicity. 1. The gbeans themselves form the interceptor stack. This means the ejb gbean needs to have an ejb context object that it sends down the stack with each call containing the info particular to that ejb, such as the transaction policy settings. Since you don't really have any idea what interceptors are present, AFAICT you either need to code generate a context object to suit the particular interceptors present, or use a map. A map is a bit slow and loses type safety, whereas code generation seems awfully complicated. I suppose it might be possible to use an Object[] and figure out the indices for each interceptor when the ejb starts. 2. The gbeans are interceptor factories, and when the ejb starts it uses the factories to construct its own personalized interceptor stack. Here, each interceptor instance can hold the context information for itself, and initializing it from a map does not have a performance penalty. On the other hand, you get more interceptor object instances. thanks david jencks -dain
Cut date for 1.1?
I have heard from some that 1.1 will be cut next week and from others that it will be at least 4 more weeks. Can we make a decision now on what the date will be? I have a fairly big change I'd like to commit sometime next week, but if we are going to cut on Friday, I'll wait until Saturday to commit it. I normally prefer it to commit my changes at the beginning of a cycle so they have a long time to bake. -dain
Re: Cut date for 1.1?
Do you mean 1.0.1 for cutting next week? Dain Sundstrom wrote: I have heard from some that 1.1 will be cut next week and from others that it will be at least 4 more weeks. Can we make a decision now on what the date will be? I have a fairly big change I'd like to commit sometime next week, but if we are going to cut on Friday, I'll wait until Saturday to commit it. I normally prefer it to commit my changes at the beginning of a cycle so they have a long time to bake. -dain
Re: Cut date for 1.1?
Nope, I mean 1.1. -dain On Jan 20, 2006, at 9:14 AM, Jeff Genender wrote: Do you mean 1.0.1 for cutting next week? Dain Sundstrom wrote: I have heard from some that 1.1 will be cut next week and from others that it will be at least 4 more weeks. Can we make a decision now on what the date will be? I have a fairly big change I'd like to commit sometime next week, but if we are going to cut on Friday, I'll wait until Saturday to commit it. I normally prefer it to commit my changes at the beginning of a cycle so they have a long time to bake. -dain
Re: Cut date for 1.1?
David Jencks wrote: Personally I am not ready for 1.1 to be frozen. Also, there is at least one major bug (tomcat cross-context dispatch) that needs to be fixed and I haven't seen any progress on it. I am not going to be able to get to this at least until Monday...you know...day job and family things to do ;-) Sorry...I wish I could expedite this...I am happy to chat about it and come up with a solution if you need it before the beginning of next week. Feel free to tackle it yourself if that time is not acceptable for you. The nature of your change might affect other peoples opinion on this also, what are you planning? I agree...I think a 1.1 cut for next week is a bit aggressive. thanks david jencks On Jan 20, 2006, at 9:19 AM, Dain Sundstrom wrote: Nope, I mean 1.1. -dain On Jan 20, 2006, at 9:14 AM, Jeff Genender wrote: Do you mean 1.0.1 for cutting next week? Dain Sundstrom wrote: I have heard from some that 1.1 will be cut next week and from others that it will be at least 4 more weeks. Can we make a decision now on what the date will be? I have a fairly big change I'd like to commit sometime next week, but if we are going to cut on Friday, I'll wait until Saturday to commit it. I normally prefer it to commit my changes at the beginning of a cycle so they have a long time to bake. -dain
Re: Cut date for 1.1?
On Jan 20, 2006, at 9:46 AM, David Jencks wrote: Personally I am not ready for 1.1 to be frozen. Also, there is at least one major bug (tomcat cross-context dispatch) that needs to be fixed and I haven't seen any progress on it. The nature of your change might affect other peoples opinion on this also, what are you planning? I am working on splitting the OpenEJB container into one object for each deployed ejb and a set of share invocation processing ejb containers. This is a refactoring of internal interfaces well below the layer our users see. Regardless, of this change, I don't want to be the one that checks in stuff that breaks the build or TCK 3 days before a branch is cut. -dain
Re: Cut date for 1.1?
On Jan 20, 2006, at 9:59 AM, Dain Sundstrom wrote: On Jan 20, 2006, at 9:46 AM, David Jencks wrote: Personally I am not ready for 1.1 to be frozen. Also, there is at least one major bug (tomcat cross-context dispatch) that needs to be fixed and I haven't seen any progress on it. The nature of your change might affect other peoples opinion on this also, what are you planning? I am working on splitting the OpenEJB container into one object for each deployed ejb and a set of share invocation processing ejb containers. This is a refactoring of internal interfaces well below the layer our users see. Does this mean there will be one interceptor stack for each ejb type, shared among all the e.g. stateless sesssion ejbs? What is the advantage of this design? I can think of some disadvantages compared to our present design but no advantages. Probably just a lack of imagination, but I'd really appreciate discussion of architectural changes before the code arrives. thanks david jencks Regardless, of this change, I don't want to be the one that checks in stuff that breaks the build or TCK 3 days before a branch is cut. -dain
Re: Cut date for 1.1?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dain Sundstrom wrote: Regardless, of this change, I don't want to be the one that checks in stuff that breaks the build or TCK 3 days before a branch is cut. Who is the release manager? If there isn't one, then there's no point worrying about any particular date. The release manager gets to call the shots on freeze, thaw, and cut dates. - -- #kenP-)} Ken Coar, Sanagendamgagwedweinini http://Ken.Coar.Org/ Author, developer, opinionist http://Apache-Server.Com/ Millennium hand and shrimp! -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iQCVAwUBQ9E9B5rNPMCpn3XdAQKmtAP/YGBUoOmSSfv/JLdWjb2qG6xGov9Ve7wE PZNO/tUbu1J7JUb3xkpN8CwUBtv6GEO9pr7T/CrR5WxgSJblmq1E5B4c+Ok2liIz YXVZoc2qYBU0tyHz7VEVNOaqMTERrL40amdez0gy08dA86dk5ySHGk1RXZqH7IKH bvVBOMPeUZk= =7yAY -END PGP SIGNATURE-
Re: Cut date for 1.1?
For what it's worth, Dain whiteboarded his plan for me the other day and I'm 100% on board with the proposed changes. Thanks, Aaron On 1/20/06, David Jencks [EMAIL PROTECTED] wrote: On Jan 20, 2006, at 9:59 AM, Dain Sundstrom wrote: On Jan 20, 2006, at 9:46 AM, David Jencks wrote: Personally I am not ready for 1.1 to be frozen. Also, there is at least one major bug (tomcat cross-context dispatch) that needs to be fixed and I haven't seen any progress on it. The nature of your change might affect other peoples opinion on this also, what are you planning? I am working on splitting the OpenEJB container into one object for each deployed ejb and a set of share invocation processing ejb containers. This is a refactoring of internal interfaces well below the layer our users see. Does this mean there will be one interceptor stack for each ejb type, shared among all the e.g. stateless sesssion ejbs? What is the advantage of this design? I can think of some disadvantages compared to our present design but no advantages. Probably just a lack of imagination, but I'd really appreciate discussion of architectural changes before the code arrives. thanks david jencks Regardless, of this change, I don't want to be the one that checks in stuff that breaks the build or TCK 3 days before a branch is cut. -dain
Re: Cut date for 1.1?
On Jan 20, 2006, at 11:42 AM, Rodent of Unusual Size wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dain Sundstrom wrote: Regardless, of this change, I don't want to be the one that checks in stuff that breaks the build or TCK 3 days before a branch is cut. Who is the release manager? If there isn't one, then there's no point worrying about any particular date. The release manager gets to call the shots on freeze, thaw, and cut dates. Um, I really disagree here. If the release is cut on Fiday and I check in code on Thrudaay that breaks the release, I'm going to get blamed regardless of who makes the decision to cut. Anyway, who is running this release and are we cutting on Friday? -dain
Re: Cut date for 1.1?
This is really a discussion for the openejb mailing list, but since you asked here I'll respond here. On Jan 20, 2006, at 11:17 AM, David Jencks wrote: On Jan 20, 2006, at 9:59 AM, Dain Sundstrom wrote: On Jan 20, 2006, at 9:46 AM, David Jencks wrote: Personally I am not ready for 1.1 to be frozen. Also, there is at least one major bug (tomcat cross-context dispatch) that needs to be fixed and I haven't seen any progress on it. The nature of your change might affect other peoples opinion on this also, what are you planning? I am working on splitting the OpenEJB container into one object for each deployed ejb and a set of share invocation processing ejb containers. This is a refactoring of internal interfaces well below the layer our users see. Does this mean there will be one interceptor stack for each ejb type, shared among all the e.g. stateless sesssion ejbs? By default, yes. The idea is you can deploy extra invocation processors that have different QoSes configured and then you assign an ejb to the processor you want. What is the advantage of this design? I think the important important advantage for OpenEJB is that this change aligns the 2 code with the 1 code. The other big advantage is that it the job of a deployer is simpler because the most complex configurations (like caches) are placed on the invocation processors which will be defined using he generic gbean xml tags. I can think of some disadvantages compared to our present design but no advantages. Probably just a lack of imagination, but I'd really appreciate discussion of architectural changes before the code arrives. The architectural change is to split the current EJB container into a service for each EJB and a shared service for invocation processing. If you want to have a discussion on this, we should move to the openejb dev mailing list. -dain
Re: Cut date for 1.1?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dain Sundstrom wrote: Who is the release manager? If there isn't one, then there's no point worrying about any particular date. The release manager gets to call the shots on freeze, thaw, and cut dates. Um, I really disagree here. If the release is cut on Fiday and I check in code on Thrudaay that breaks the release, I'm going to get blamed regardless of who makes the decision to cut. I see no disagreement. That's right, if the release manager says 'no more commits' and you go ahead and commit, you're going to get blamed whether it breaks things or not. It's the release manager's responsibility to coordinate dates so that such brokenness gets detected before the freeze. One possible scenario would be for the RM to say, 'Okey, we're frozen. Regression tests run now. If nothing pops up, we'll cut and then unfreeze and go back to commit mode.' It's the RM's call. - -- #kenP-)} Ken Coar, Sanagendamgagwedweinini http://Ken.Coar.Org/ Author, developer, opinionist http://Apache-Server.Com/ Millennium hand and shrimp! -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iQCVAwUBQ9FpqprNPMCpn3XdAQL1EAQAnN9gGYfu+++gZMRGc3vbq5w1RS3dllki JBnVoGUDgcGsTbEVMMCOkzuqDlacTAD62cSwBTxpEFp5s/S0q/nxOG6BAFUwLli6 TrCF3avuNAQM85UlDog/XyXN1wczWW5l0Wwjxv1TfXTb42nYJ0yhx6Fxtc+Q51zz jxzymExJYN4= =uZ3b -END PGP SIGNATURE-
Re: Cut date for 1.1?
Dain Sundstrom wrote: I have heard from some that 1.1 will be cut next week and from others that it will be at least 4 more weeks. Can we make a decision now on what the date will be? I have a fairly big change I'd like to commit sometime next week, but if we are going to cut on Friday, I'll wait until Saturday to commit it. I normally prefer it to commit my changes at the beginning of a cycle so they have a long time to bake. -dain I am assuming you mean cut a branch for the 1.1 release. I think we need to identify what it is that is being delivered (from an end user point of view) in the 1.1 release. What is in 1.1 that is worth delivering so soon? Wouldn't it be better to wait a bit after the 1.0.1 release that has been proposed so any bugs fixed for 1.0.1 are in trunk prior to branching for 1.1? I did a quick JIRA search of all New Features, Improvments, Wishes and Tasks that are resolved and completed (I excluded bugs, as they should be merged to the 1.0 branch for the 1.0.1 release). The search only resulted in 11 JIRAs. If there is more that is going in 1.1 than JIRA is showing then could people please speak up and update their JIRA records to reflect reality. John
