Grzegorz Kossakowski skrev:
Hello,
I'm not sure if anyone tracks implementation of COCOON-2050 issue. The
status is that basic infrastructure is implemented and almost works as
expected. Some really basic samples are provided too.
Almost refers to the problem with serializer that makes servlet calls.
Currently, method returning mime type cannot be implemented because it's
up to called service to determine mime type. The getMimeType is called
during pipeline's setup phase but servlet call is done during processing
phase so serializer has no chance to return proper mime type during
setup phase.
Looking at the AbstractProcessingPipeline the getMimeType method of the
serializer is called from the setMimeTypeForSerializer method that in
turn is called in the beginning of the processXMLPipeline method
*before* the generator.generate() method that lead to the actual
execution of the serializer. I might be missing something, but AFAICS
the call of the setMimeTypeForSerializer method call could be moved to
*after* the generator.generate call without changing the result at all.
And by changing this the ServletServiceSerializer could use the response
mime type from the internal servlet service call as return value for the
ServletServiceSerializer.getMimeType() method. The caching pipelines
would of course need to be changed in a similar way.
Another problem is that if we want servlet services really usable we
need to forward Environment to the called service. An obvious example is
service that takes effort of styling Forms and handling Ajax requests.
It needs to access all environment data to get run Forms machinery
properly. I was thinking about it for a while and I have no appealing
idea how to solve it. I guess that this task is far beyond HTTP
capabilities and in this area we need to break conformity with HTTP
specification. I mean that we just attach Environment object to the
BlockCallHttpServletRequest instance and we'll modify cocoon's core a
little bit to detect that request is service call so it will be able to
make us of forwarded Environment.
What do you think?
That would make the servlet-service-impl dependent on
cocoon-pipeline-api, which I wouldn't like at all. The idea with the
servlet service stuff is that it should be independent of the rest of
Cocoon.
First I wonder why the forms frame work depend on Environment specific
things and not just what is present in the standard http request object.
But if we leave that for the moment I think that the best way to pass
information (e.g. request, response and maybe environment object) in the
call chain in an unintrusive way is by using a call stack. I implemented
a fairly generic call stack in o.a.c.callstack in the
cocoon-servlet-service module. It also provide a custom Springframework
call scope (see
http://static.springframework.org/spring/docs/2.0.x/reference/beans.html#beans-factory-scopes-custom
about custom scopes) that makes it possible to get the "current"
environment object through ordinary dependency injection.
The call stack o.a.c.environment.internal.EnvironmentStack in
cocoon-sitemap-impl is used internally in the sitemap for passing
environment info to e.g. subsitemaps and Cocoon calls. By refactoring it
so that it used the o.a.c.callstack stuff internally, we could have a
common callstack both for block calls and sitemap internal calls. Then
environment info and other servlet specific info could be passed in an
unintrusive way.
WDYT?
/Daniel
