You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by bu...@apache.org on 2015/10/14 11:49:12 UTC
[Bug 58497] New: Unable to have a custom implementation of
AbstractHttp11Processor due to package private methods
https://bz.apache.org/bugzilla/show_bug.cgi?id=58497
Bug ID: 58497
Summary: Unable to have a custom implementation of
AbstractHttp11Processor due to package private methods
Product: Tomcat 7
Version: 7.0.54
Hardware: All
OS: All
Status: NEW
Severity: critical
Priority: P2
Component: Connectors
Assignee: dev@tomcat.apache.org
Reporter: amit_pande@symantec.com
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.
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
[Bug 58497] Unable to have a custom implementation of
AbstractHttp11Processor due to package private methods
Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=58497
--- Comment #1 from Mark Thomas <ma...@apache.org> ---
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.
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
[Bug 58497] Unable to have a custom implementation of
AbstractHttp11Processor due to package private methods
Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=58497
Mark Thomas <ma...@apache.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Resolution|--- |FIXED
Status|NEW |RESOLVED
--- Comment #3 from Mark Thomas <ma...@apache.org> ---
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.
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
[Bug 58497] Unable to have a custom implementation of
AbstractHttp11Processor due to package private methods
Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=58497
--- Comment #4 from Amit Pande <am...@symantec.com> ---
Thanks a lot, Mark, all for your quick responses and invaluable suggestions.
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
[Bug 58497] Unable to have a custom implementation of
AbstractHttp11Processor due to package private methods
Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=58497
Amit Pande <am...@symantec.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |amit_pande@symantec.com
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
[Bug 58497] Unable to have a custom implementation of
AbstractHttp11Processor due to package private methods
Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=58497
Amit Pande <am...@symantec.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEEDINFO |NEW
--- Comment #2 from Amit Pande <am...@symantec.com> ---
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.
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
[Bug 58497] Unable to have a custom implementation of
AbstractHttp11Processor due to package private methods
Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=58497
Violeta Georgieva <vi...@apache.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |NEEDINFO
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
[Bug 58497] Unable to have a custom implementation of
AbstractHttp11Processor due to package private methods
Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=58497
Amit Pande <am...@symantec.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Priority|P2 |P1
Severity|critical |blocker
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org