cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Grzegorz Kossakowski (JIRA)" <>
Subject [jira] Updated: (COCOON-2038) Implement true Object Oriented approach for handling super calls
Date Tue, 10 Jul 2007 22:31:04 GMT


Grzegorz Kossakowski updated COCOON-2038:

 (In reply to comment #6)
> Hi,
> I am sorry for delaying so long to reply your messages because I has been too
> busy for the past 2 weeks.

No problem.

> The following is the description of my implementation:
> I use the same reason as described by Daniel above to implement this function.
> However, in addition to
> the returned status code, I also use ServletException to tell that a function
> might be implemented in a super
> servlet service. Lets say servlet service s1 extends servlet service s0. A
> request r asking for functin f is handled
> by s1 unsuccessfully because either an instance of ServletException is thrown or
> the returned status code
> is not between 200 to 399, r is then handled by s0. The code is implemented in
> method 'forward' method of the
> inner class PathDispatcher of ServletServiceContext.

I think I have found a bug in your implementation in forward method. The problem is that you
delegated handling of all super-related stuff to getNamedContext() method. This solution is
quite reasonable because it's better to have one place that will handle super calls but then
superCall in NamedDispatcher will have wrong value set. Basically, it will make NamedDispatcher
unaware if it's super call or not.

Do you have any proposals how to fix it in elegant way?

> However, since there is not a method getStatus() in HttpServletResponse, I
> define a new interface called
> StatusRetrievableResponse which just contains a method getStatus(). Then I
> change the method 'service'
> in DispatcherServlet to wrapp the passed-in repsonse 'rep' to make the response
> implement StatusRetrievableResponse
> in order to let getting status possible in the method 'forward' in
> PathDispatcher.

I think that introduction of that interface is over-engineering. Where else can it be used?
What other implementations we are likely to see?
As for now I'm against introducing it; we can always refactor the code if we need to extract
any interface.

> On the implementation, I find 2 bugs in ServletServiceContext. The first one
> is in the method
> getNamedContext in ServletServiceContext. It does not look up super servlet for
> a named connection.

I'm not sure if it's a bug really, see below.

> The second one is in the constructor of the inner class NamedDispatcher of the
> ServletServiceContext.
> I have to use an example to tell this bug. Let say the above servlet service s0
> have a link (but not a super link)
> to another servlet service s3. When s1 invokes s3, current implementation treats
> this invocation as super invocation. I think
> this is not right. So I remove some lines of code which doing the supperCall
> setting in the NamedDispatcher constructor.

My understanding of superCall field is that it should have "true" value if it make a call
to super servlet or to servlet connected by super servlet. If my understanding is correct
then previous implementation was proper.

> I attach one file patch this time.

This helped me a lot, thanks!

> Implement true Object Oriented approach for handling super calls
> ----------------------------------------------------------------
>                 Key: COCOON-2038
>                 URL:
>             Project: Cocoon
>          Issue Type: Task
>          Components: - Servlet service framework
>            Reporter: Grzegorz Kossakowski
>            Assignee: Grzegorz Kossakowski
>             Fix For: 2.2-dev (Current SVN)
>         Attachments:, cocoon-servlet-service-impl.patch,,,
> As discussed here: implementation
of super calls should be changed to make it more OO-like.

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message