My original approach was to relay on the commonly known and available abstractions. This should limit the amount of dependencies of proprietary abstractions. Because of this I will be in favor to use the real servlet abstraction - HttpServletRequest and HttpServletResponse. Those are publicly available and everybody has jars defining them. In the case of publishing framework, where the dominant transport is HTTP it looks reasonable to relay on servlet abstractions. This will be my approach.
I have no problem accepting the fact that Cocoon made the choice to not use them. But in such case I like to see the internal abstraction to be able to provide full functionality equivalent to the original servlet abstraction, then to use it across the board. As you remember at some point StreamGenerator was patched to use real servlet abstraction, because it was some scenario where HttpRequest was not good enough. I do not remember exactly what was the problem but I do not like special cases situations, it is bad programming practice. Then my proposition is to make the choice use one abstraction: HttpServletRequest/HttpServletResponse or Request/Response or HttpRequest/HttpResponse But no back door allowed. I was forced to use HttpRequest not Request because Request did not define getInputStream() method fundamental to the processing I was doing. It is interesting to see that HttpRequest implements Request and adds some implementations of HttpServletRequest interfaces not defined in Request for ex. getInputStream. Is it by design or but mistake? I need to analyze today's Request/HttpRequest relationship. At the moment I was doing my implementation it was a little "mass" there. I will compare them again and sent the results. Kinga > -----Original Message----- > From: Carsten Ziegeler [mailto:[EMAIL PROTECTED]] > Sent: Friday, February 08, 2002 4:21 AM > To: [EMAIL PROTECTED] > Subject: RE: Dispatcher/Adapter > > > > > DZIEMBOWSKI,KINGA wrote: > > > > Hi, > > I feel that the tension of release is over, and we can return to the > > discussion on my proposal. I propose to add to the Cocoon project > > Dispatcher/Adapter concept. This set of interfaces and > basic abstraction > > allows building pluggable extensions in a more standardized > way. The real > > life example of such extension is our HP-SOAP Server. (You > can download it > > from http://www.hpmiddleware.com/download.) But it is just one > > example, the > > imagination can bring much more. > > > > To refresh your memory the proposal, demo , patches and > additions can be > > found at: > > http://soap.bluestone.com/proposal. The real HP-SOAP server in > > action can be > > accessed by: > > http://soap.bluestone.com/hpws. > > Please note the combination of Cocoon publishing techniques, XSP > > pages used > > as client forms to access SOAP services, with processing > capabilities. > > > Hi Kinga, > > yes we should now come back to this. As some of us here have > already stated, > we are very happy about your donation and will accept it. > > But, there is this *little* problem with HttpRequest vs > Request problem. > If I remember it right, your solution requires some methods > which are not > exposed > by the Request object (or Response object?). > > I thought a little bit of this problem and I think this is a > general problem > Cocoon has. So perhaps we can solve this on a higher level. > > There are several custom libraries/projects which rely on the > HttpRequest/HttpResponse > interface exposed by the Java Servlet API. Cocoon decided not > to use the > servlet > abstraction but an own one to easier integrate Cocoon into other > environments like CLI > or whatever. > To integrate all these custom libraries (like the HP donation, the PHP > generator > or the Deli component) there are currently two hacks used: > a) A custom component wraps the Cocoon Request/Response > objects to provide > the full > Servlet API functionality > b) The HTTP environment puts not only the Cocoon > Request/Response but also > the Servlet > variants into the objectModel, so they can directly used by custom > components. > > Now, I would like to be able to use all these great custom > projects inside > Cocoon > *without* the Servlet API even from CLI. So I think we need > an *interface* > from Cocoon > to custom services using the Servlet API. > An easy solution would be to provide a > HttpRequest/HttpResponse object in > the objectModel > by the environment as it is already the case today with the HTTP > environment. > > Are there better solutions? Is this FS? > > Regards, > Carsten > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, email: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
