Sorry. I'm a bit behind on my keel reading. Will catch up this evening
and reply to / weigh in on whatever needs my input.
Santanu is on vacation in Las Vegas... so we'll hit him up for his input
when he returns.
As for the 1.0 / head issue... I finally got smart and checked out the
head in a new eclipse workspace. This means that even though I am using
the 1.0 Branch... it is now a much easier task for me to make important
changes to both branches (in fact, I did that last week).
This means that I don't expect to continue to pay just lip service to
the concurrent modification issues, and instead I will try to really
update both branches where practical.
-Phil
On Thu, 2003-09-11 at 18:05, Stephen Davidson wrote:
> Hi Shash.
>
> Thanks for the info.
>
> I am hoping Santanu and Philip weigh in here as well, as they have done most of the
> work on the 1.0 branch, and it is their work that I want to merge into the 2.0
> branch.
>
> As far as ModelAction is concerned, happily that is a clnt-struts object, so this is
> a good place to put struts specific stuff. The only Keel specific object that there
> is a conflict with is NestedException. And that is an object that I am wondering if
> we can get rid of.
>
> As for svc-struts-fileupload, it would be nice to find out if this can be made more
> generic, as the application I am working will eventually have to support multiple
> clients.
>
> Regards,
> Steve
>
> --
> Java/J2EE Developer/Integrator
> Currently "On the Road"
> 214-724-7741
>
> ----- Original Message -----
> From: Sasvata (Shash) Chatterjee
> Sent: 9/11/2003 2:04:28 PM
> To: [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED]
> Subject: Re: [Keelgroup] Merge 1.0 -> HEAD : First Pass is done
>
> > Steve,
> >
> > 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
> >
> >
> [snip to save bandwidth]
>
>
> 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
