| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This updates Jetty to the latest 9.x version as of writing. The 9.x is
still running on Java 8. The update needs two code changes.
`SessionManager` was replaced with `SessionHandler`. This was documented
in the Jetty documentation.
Adding the `GitblitContext` to the `WebAppContext` will result in two
instances getting created, because the code was changed that prevents
instantiation the same listener class multiple times. (The second time
is when the web.xml is read.) Instead, it must be added to the servlet
handler of the `WebAppContext`. This results in properly adhering to the
changed internal startup flow.
Updating Jetty also resolves #1409.
|
| |
|
|
|
|
|
|
|
| |
Jetty 9.3 changed the `setHandler` on the ServletContextHandler to no
longer automatically detect SecurityHandler, SessionHandler, etc. It
simply passes on the setHandler request to the ContextHandler class
(with a warning logged). So make sure to explicitly use the method
`setSecurityHandler` to set the ContraintSecurityHandler responsible
for the http -> https redirection.
|
| |
|
|
|
|
|
|
|
|
|
| |
Instead of adding another setting and having to explain how the new one
and the existing `requireClientCertificates` setting are interdependent,
let's use the existing setting and add new values.
It is changed from a boolean to a string, with the values `required`,
`optional` and `disabled`. To keep backward compatibility with the old
values, the `true` value is mapped to `required` and the `false` value
is mapped to `optional`.
|
| |\
| |
| |
| | |
oddeirik-disable-client-certs
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The (moxie and other) Launcher do not work with Java 9 and later anymore.
It used to dynamically extend the classpath, misusing an internal
interface of the `URLClassLoader`. This is no longer possible since Java 9,
which closed that path and does not offer any way to dynamically extend
the classpath during runtime.
So the choice is between providing one large Jar with everything in it,
providing a Jar that has the Jars in `ext` listed explicitly in its
manifest, and specifying the classpath on the command line where
the `ext` directory can be added and all contained jar files will
be put on the classpath.
The motivation for the Launcher class was to be able to simply drop
new jar files into a directory and they will be picked up at the
application start, without having to specify a classpath. We opt
for solution three here. This way jar files can still be dropped
into the ext directory, albeit the directory needs to be added to
the classpath on the command line. Unfortunately using a wildcard
is not possible in the manifest file. We change the calls in the
script files accordingly. This seems like a good compromise,
since no one will run the application manually typing the whole
commandline anyway.
This also does away with the splash screen, by the way. Again,
doesn't seem like a big loss, as I don't think it was ever shown
for the Authority.
Personally, I am not convinced that it is the best way, because
I don't really think that the use case of dropping whatever jar
files into the `ext` directory is a valid one that happened a lot.
This does not yet fix the client programs, which still use a
Launcher. Maybe for them a all-in-one Jar is a better solution.
Fixes #1262
Fixes #1294
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
With three versions about to be supported right now
it is getting more important to know which Java version is
used when building and testing Gitblit, and which Java
version is used to run Gitblit.
So have the Moxie build report the javac version, and the
JVM version that Moxie is running on. These might be
different.
The `GitBlitServer` will print the Java version and vendor,
so that it gets visible if a user would paste a log output
for analysis.
|
| | | |
|
| | |
| |
| |
| |
| |
| | |
server.httpTimeout
setting to allow cloning big repositories over HTTP. This change fixes the java.util.concurrent.TimeoutException issue described in https://groups.google.com/d/topic/gitblit/UvDC48NpmF4/discussion .
|
| |/
|
|
|
|
| |
So far for session cookies the secure property was only set when no
HTTP port was opened. This changes to also set it when HTTP is redirected
to the HTTPS port.
|
| | |
|
| |\ |
|
| | | |
|
| |/ |
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
Gitblit would greatly benefit from an integrated SSH server. This would
complete the transport trifecta.
Change-Id: I6fb95abe65655fa74d47ea71522d8d9a1541450c
|
| | |
|
| | |
|
| |
|
|
| |
Change-Id: I5f0f50f4ae7d332e9f724a2e6f074fa71f646035
|
| |
|
|
| |
Change-Id: I5358389396f816da979ec18a31421c2d2b67b3d9
|
| |
|
|
| |
Change-Id: If3f30af2ed250968e65cde58bd413213f4d384b1
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
These manager interfaces define how the GitBlit singleton will
eventually be split into smaller component managers. The Wicket app and
all servlets have been updated to request the needed managers. There
are _very_ few method signature changes - although there are a handful.
This is a surgical sharding of responsibility based on a proof of
concept refactor. Instead of random references to GittBlit.self()
there are now precise references to the manager interface required to
accomplish some task. Some tasks may require references to multiple
managers.
The code is now littered with calls to GitBlit.getManager(class) and
those familiar with the code-base will no doubt notice the duplication
of methods from IUserService in IUserManager and the addition of
implementation methods in the GitBlit context class. When the
GitBlit class is broken apart and the existing external authentication
user service classes are refactored to AuthenticationService classes,
this will again simplify and flatten. But in order to safely and
cleanly modularize the stable code-base we will have to live with a
little duplication for a short while.
Change-Id: I7314ec8acaab2dcc6092785ed4434cc09fdbbe16
|
| |
|
|
| |
Change-Id: I33966b8292434c10ffd623838d09527aaebaca5f
|
| | |
|
| |
|
|
| |
Change-Id: I9f91138b20219be6e3c4b28251487df262bff6cc
|
| | |
|
| | |
|
| | |
|
| | |
|
|
|
This is a massive commit which reorganizes the entire project structure
(although it is still monolithic), removes the Build classes, and
switches to Moxie, a smarter Ant build tookit based on the original
Gitblit Build classes.
The Ant build script will likely require additional fine-tuning, but
this is big step forward.
|
