Bug 58497

Summary:	Unable to have a custom implementation of AbstractHttp11Processor due to package private methods
Product:	Tomcat 7	Reporter:	Amit Pande <amit_pande>
Component:	Connectors	Assignee:	Tomcat Developers Mailing List <dev>
Status:	RESOLVED FIXED
Severity:	blocker	CC:	amit_pande
Priority:	P1
Version:	7.0.54
Target Milestone:	---
Hardware:	All
OS:	All

Description Amit Pande 2015-10-14 09:49:12 UTC

http://grepcode.com/file/repo1.maven.org/maven2/org.apache.tomcat/tomcat-coyote/7.0.54/org/apache/coyote/http11/AbstractHttp11Processor.java#AbstractHttp11Processor

Class org.apache.coyote.http11.AbstractHttp11Processor is marked as a "public abstract" class. However:

 abstract boolean  [More ...] prepareSendfile(OutputFilter[] outputFilters);

The above method "prepareSendfile" is not marked as public ( i.e. made a package private) and thus cannot be overridden from an extending class which is outside of the "org.apache.coyote.http11" package.

Same can be said for :   "abstract void  actionInternal(ActionCode actionCode, Object param)" method as well.

We have a requirement of having a custom implementation for AbstractHttp11Processor but now we cannot because these methods cannot be overridden unless we modify in the tomcat source code. Thus this is proving a blocker for us.

Is there any specific reason these were made "package private" because the class itself is abstract & public ? 

Am not too sure but this might be applicable to latest tomcat (e.g.8 ) versions too.

Comment 1 Mark Thomas 2015-10-16 06:37:54 UTC

That class is not considered part of Tomcat's public API (see the README file). It is liable to change between any point release.

What is the underlying requirement that means you need to extend that class?

Note that in 9.0.x this class no longer exists and it is likely the same changes will be back-ported to 8.x in the near future.

Comment 2 Amit Pande 2015-10-23 10:30:32 UTC

Apologies Mark & Violeta for a delayed reply. Trying to explain below what we need off tomcat.


"Requirement is to have multiple custom Acceptor strategy and at least each
Acceptor strategy is taken up by one thread.

One and possibly many acceptor thread could be listening for incoming
HTTP/S request.
One acceptor thread would be accepting request from legacy JNI which in
turn registers with a custom service handlers to accept incoming requests.

In  the current framework this is not possible or at least I could not
figure out how to do it.

So easiest way I found was to copy paste default connector code and change
acceptor strategy.
Now I have two connectors, default one listening for HTTP/S request.
Custom connector acceptor thread relying on JNI library for handing over
to it new connection from custom service handler. "



Would really appreciate if you could point to appropriate way to solve this issue.

Comment 3 Mark Thomas 2015-10-25 13:53:41 UTC

Tomcat's connectors were originally designed with this sort of use in mind although it is likely that over time some changes have crept in that are unhelpful in this regard.

Ideally, you should be able to do this by extending existing abstract base classes / overriding existing implementations depending on how close the current code is to what you need. If you spot changes (splitting up methods, changing visibility, adding accessors, etc.) that would make this easier we are happy to consider them. (Please open additional BZ issue for such requests.)

I have made the methods in question protected in 8.0.x and 7.0.x.

The connectors were refactored further in 8.0.x and significantly so in 9.0.x. It is worth you taking a look at 9.0.x as  that is still in development and any changes you might need so enable a future upgrade to 9.0.x will be much easier to make sooner rather than later.

Comment 4 Amit Pande 2015-10-26 05:37:00 UTC

Thanks a lot, Mark, all for your quick responses and invaluable suggestions.