I can't devote much time to this at the moment, but I can help you out with some idea of the refactorings that went into this side of Keel in 2.0. You'll find the content of the 1.0 ModelAction has been broken up into three pieces.
The common part of what any Keel client would need to do, including encapsulation of the JMS connectivity, has been abstracted to org.keel.clients.AbstractKeelClientConnector (in keel-server). The next piece up the chain is the common piece that all webapps (Struts, Velocity, Cocoon, but not CLI) need to do, particularly convert HttpRequest/Response to KeelRequest/Response: and that is in org.keel.clients.webapp.AbstractWebappClientConnector (in keel-server). Next, the common part that *all* Struts actions would need to do is in org.keel.clients.struts.StrutsClientConnector. Finally, ModelAction becomes just the default action (you can see how little code it has), but any action can use the same code to access Keel as necessary.
I don't think Eclipse's or any other merge tool will help here, it needs to be done manually with a lot of thought and care. The current ModelAction as you checked in doesn't seem the right thing to do. To merge the functionality from Santanu's changes to 1.0 ModelAction into 2.0, I'd recommend diff'ing the 1.0.1 tagged ModelAction.java to Santanu's version to identify what actually changed. You should be able to find similarities with the original ModelAction in the three pieces of code I mentioned above, and then make similar changes from the diff in each piece as appropriate.
I have a couple of concerns that I would like to bring up. I think the Struts-specific parameters and functionality should stay only in clnt-struts. The org.keel.clients.webapp package should contain generic code that is applicable equally to Struts, Cocoon, Velocity, etc...i.e. all web clients. So, if translation from Struts to a generic parameter passing scheme needs to happen, the place to do it is StrutsClientConnector. The next is more something Santanu can address. I haven't looked at it yet, but svc-struts-fileupload sounds like it is Struts-specific, but if you write a model using it, you can't use Cocoon any more for your app. Are we breaking the "Any Service, Any Deployment" part of our motto? Can this be made generic? Or maybe it is not a generic Keel-server-side service, but part of the keel-client functionality that needs to be moved over to clnt-struts?
Shash
Stephen Davidson wrote:
Greetings.
My first pass at merging clnt-struts & keel-core 1.0 -> Head is complete.
HOWEVER, there are two objects where developer teams diverged remarkably and incompatably; ModelAction (execute method) from clnt-struts, NestedException from keel-core.
If Mike Nash, Shash, Santanu, and Philip Brown would be so kind as to have a look and come up with the actual solution, it would be appreciated.
I checked in a modified version of ModelAction. BOTH versions of the execute method are present, with the 1.0 version called execute1_0.
With NestedException, the handle it was keeping to the exception that caused the current exception was removed due to serialization issues. This removal breaks some code in the HEAD version of ModelAction.execute.
About NestedException. I would like to vote on removing this class (or at least deprecating it). Starting with JDK 1.4, Throwables all implement Serializable (this may have been present before 1.4, not sure) and now have a Cause property, which is the Throwable which caused the current Exception. As a result, the bulk of the methods provided by this class are now already provided by Throwable, perhaps making this class redundant.
Looking forward to seeing this merge completed.
Regards, Steve
PS: I ran "ant tests" before I checked in, and everything passed.
PPS: Eclipse has a number of Wizards to merge code from HEAD to a given branch. Would it be possible that once this merge was done, for all developers to develop on HEAD, and merge to 1.x as needed? The Eclipse Merge Wizard should make this a snap.
-- Java/J2EE Developer/Integrator Currently "On the Road" 214-724-7741
http://keelframework.org/documentation
Keelgroup mailing list
[EMAIL PROTECTED]
http://lists.keelframework.com/listinfo.cgi/keelgroup-keelframework.com
http://keelframework.org/documentation Keelgroup mailing list [EMAIL PROTECTED] http://lists.keelframework.com/listinfo.cgi/keelgroup-keelframework.com
