Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jetty-dev] Jetty API

Gunnar,

Its really hard to say on this...

While jetty has been supporting osgi for many years there has never
been an really strong effort to support the internal/external concepts
of osgi.  I would say the general rule of thumb is that from minor
release to minor release we maintain the broad top level interfaces,
things like Connection, Server, Context, etc.  These things we take
care to maintain api compatibility with.  Across point releases you
are likely to see additive changes to some of the lower level
interfaces and internal implementations of classes but here we
generally try and not break things.

From an osgi perspective our goal between versions is generally to not
break things, but if we do then in easily fixable ways.  Because we
don't support the internal/external package isolation convention we
really can't guarantee seamless updates from all minor versions like
osgi is really aiming for.  To do that under the current codebase
organization would paralyze us as everything is basically 'api' in
osgi terms.  So we recommend that you set your version ranges to
specific releases and not rely 100% on seamless updates from point
version to point version of jetty.  That is not to say that most of
the time it won't work fine as people generally don't override jetty
classes at the level you are in this case.  You caught one of the edge
cases here, sorry.

Now we did just sink some time into formalizing the approach to get
certificates and whatnot for ssl connections so we are open to further
pushing that mechanism to supporting and api that makes your life
easier on that front as well.  If you like open a bugzilla issue on
what your requirements are and we can see about making that
configuration mechanism more extensible for your use case.  Odds are
if you are doing it someone else is as well, or will be down the road.

cheers,
jesse

--
jesse mcconnell
jesse.mcconnell@xxxxxxxxx



On Wed, Mar 16, 2011 at 02:36, Gunnar Wagenknecht
<gunnar@xxxxxxxxxxxxxxx> wrote:
> 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/
>
> _______________________________________________
> jetty-dev mailing list
> jetty-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/jetty-dev
>


Back to the top