[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Greetings Jetty Committers,
I'm embedding Jetty into a platform. As part of this I extended a few
Jetty classes and wrote some custom handlers to have a better
integration with the platform. When updating from 7.2.2 (Indigo M5) to
7.3.1 (Indigo M6) I had a few compile errors because of breaking
signature changes as well as removed/refactored code. Thus, I'm
wondering if I'm doing something wrong and relying on non-API code which
is allowed to break between minor release.
I'm looking for some doc/guidance to identify API and non-API.
Unfortunately it isn't possible from reading the package name. Any help
is appreciated!
Please don't get me wrong. It's absolute fine if what I'm doing is not
supported at all (i.e. non-API). I really just need to identify that so
that I can set more tight package imports in those cases.
FWIW, the breaking changes where refactorings in
SslSelectChannelConnector and AbstractHandler/ContextHandler.
In my handler I was overriding dump(Appendable, String) which changes
its visibility from protected to public. I was also calling
dumpHandlers(Appendable, String) which has been removed. That was a low
hanging fruit.
Previously I was subclassing SslSelectChannelConnector in order to
re-implement getKeyManagers and getTrustManagers methods. The
KeyStore(s) in the platform aren't located in the local file system but
in a different data store. That's why I loaded them directly. Those
methods were removed completely and moved to SslContextFactory. I was
able to re-implement my behavior by subclassing SslContextFactory and
overriding #getKeyStore there. Although I had to set a dummy keystore
and truststore path or the method wouldn't be called at all.
Thanks,
Gunnar
--
Gunnar Wagenknecht
gunnar@xxxxxxxxxxxxxxx
http://wagenknecht.org/
