| Name | Modified | Size |
|---|---|---|
| .. | ||
| commons-net-3.3-sources.jar | 9 years ago | 404 KB |
| commons-net-3.3.jar | 9 years ago | 274 KB |
| ftp4j-1.7.2.jar | 9 years ago | 67 KB |
| jackson-annotations-2.4.0.jar | 9 years ago | 38 KB |
| jackson-core-2.4.2.jar | 9 years ago | 220 KB |
| jackson-databind-2.4.2.jar | 9 years ago | 1.03 MB |
| jjwt-0.6.0-sources.jar | 9 years ago | 103 KB |
| jjwt-0.6.0.jar | 9 years ago | 102 KB |
| jna-4.2.1.jar | 9 years ago | 1.08 MB |
| log4j-api-2.5.jar | 9 years ago | 143 KB |
| log4j-core-2.5-sources.jar | 9 years ago | 901 KB |
| log4j-core-2.5.jar | 9 years ago | 1.05 MB |
| log4j-slf4j-impl-2.5-sources.jar | 9 years ago | 20 KB |
| log4j-slf4j-impl-2.5.jar | 9 years ago | 22 KB |
| zip4j-1.3.2-sources.jar | 9 years ago | 100 KB |
| zip4j-1.3.2.jar | 9 years ago | 128 KB |
| Change | User | Description | Committed |
|---|---|---|---|
| 19362 | tjuricek | Initial approach to running an upgrade, which basically gets past one stupid issue where t...he trust files already exist. This is likely not going to be how we exactly test. We'll probably want to run some before and after verifications, for example, to modify configuration and ensure it isn't touched during upgrades. But it's a starting point for further work. « |
9 years ago |
| 19338 | tjuricek | Create custom reporting mechanism to allow for clear "multiple suite" reports... with log...ging! This standardizes on log4j 2 as the backend (was just used on the server side). We have an "in memory appender" that we use to capture results during testing, which we associate with each method run. The whole system spits out yaml files for each suite run, which are then read in via a final task and a single html report is spit out with ... everything... in it. « |
9 years ago |
| 19002 | tjuricek | Improve API to interact with multiple p4ds. The configuration now requires an explicit... setting of what P4Ds HWS can talk to via the 'P4D config dir', where there's a file indicating connection settings per p4d, and importantly, an ID. This is the "server ID" referenced everywhere. Most methods now require a server ID to indicate which p4d to manipulate. In the future, it's likely we will interact with *multiple* p4d instances on some services. This completely removes the ability to run HWS as a kind of an "open proxy" to whatever p4d you want. Given the nature of the change and the lack of priority, we've removed Helix Cloud testing and disabled several methods from their "Helix Cloud" implementation. These will be relatively easy to bring back, we'll just need a new method from Raymond that lists the "allowed server IDs" that map to the HWS configured server IDs for a particular user. Another notable aspect of this change is the use of JSON Web Token to create our authentication key. We associate this key with an in-memory "session" that contains the P4D tickets we use to authenticate users. The JWT token, by default, is assigned a timeout, which allows HWS to block further access to underlying servers without having to interact with multiple auth backends. If any backend fails with that session, the user will get a 403. If you disable the timeout, you'll need to ensure your clients clear out sessions. « |
9 years ago |
| 18273 | tjuricek | Add automation implementation to deploy the binary archive on Linux and Windows | 9 years ago |
| 17140 | tjuricek | Integrating porting work from development branch. This work is now ready for testing/CD... integration. « |
9 years ago |