Repository navigation
Feature/1004 update javalin drop tomcat - #1985
MikeNeilson wants to merge 62 commits into
Conversation
|
NOTE: at best I will have the annotations updated today. Getting the API running again in it's standalone mode will likely take until the end of the week if not longer. |
|
For the record. I have considered keeping with tomcat and just using like embedded tomcat for the packaging, but Javalin was made for Jetty so since that would be a fair amount of work anyway, better to use a tool that was actually built for this given style of packaging an app. |
|
FYI, I am aware this PR is rather huge. The OpenAPI changes basically have to be all or nothing. I think we can all agree on that. It also requires the migration to Jakarta EE (javalin update) which would may or may not (java.security.Principal so probably not) affect the CwmsAaaIdentityProvider. So fair amount of changes to Tomcat anyway. So is this likely to be a pain... yes, but I'm arguing it's worth it. I could pivot back and do the move to standalone Javalin (e.g. Jetty whatever version that was) first, but then without updating javalin frankly it wouldn't be in a releasable state (security concerns, that's a really old Jetty) So. for now I'm going to barrel through. I'm open to addressing concerns and pivoting if they're strong enough. We do have a lot of plans. and the bulk are passing. What's failing is most likely various validation I've intentionally disabled due to the location of initialization changing. |
15a7212 to
6829e73
Compare
|
|
||
|
|
||
|
|
||
| //TODO: The rest |
There was a problem hiding this comment.
Are these gonna get added back or dropped. Some of this commented out stuff seems important
There was a problem hiding this comment.
Still figuring that out. I did get the scheme processor working,
but the returned OpenAPI object is now a builder from javalin-openapi that doesn't behave the same way... plus most of what we were doing here can no be moved to the controllers, like examples.
so I might decide to let those go for this PR, and then come back and do a follow up on them. As much as I want it all to work. at a minimum if this gets merged into main it needs to work for existing usage. And there's already new work that not going to be super trivial to rebase into this.
| } | ||
| classpath += configurations.tomcatLibs | ||
| classpath += configurations.baseLibs | ||
| jvmArgs += "-Dlogback.configurationFile=${projectDir}/logback-tests.xml" |
There was a problem hiding this comment.
should this be logback-test.xml ?
There was a problem hiding this comment.
.... that would explain some issues with what was visible.
There was a problem hiding this comment.
Not because of your change but this class looks wonky, ApplicationException already has a details map. We should be able to build a map with our extra key and pass it to super and we're done. We don't have to hold our own "details" map and modify it after the super call.
There was a problem hiding this comment.
good point... which means the QueryParameters is likely just as wonky, I copy pasted it from that.
| }); | ||
| configureRoutes(config.routes, metrics, cdaAccessManager); | ||
| }); | ||
| QueueManager.ensureRssSubscribers(ds); |
There was a problem hiding this comment.
Its kinda gross that ensureRssSubscribers(ds); gets called from the constructor. That means you can't build the object without it touching the database. Maybe it could move to the first line of start() ?
There was a problem hiding this comment.
hmm, seams reasonable.
There was a problem hiding this comment.
though then there's no reference to the DataSource (easily). good idea though, will think about best place. Maybe just save a simple reference to the datasource.
Co-authored-by: Ryan Ripken <89810919+rma-rripken@users.noreply.github.com>
MikeNeilson
left a comment
There was a problem hiding this comment.
Thanks. Definitely more to do than what you've already pointed out. But that'll be some good cleanup before starting it.
There was a problem hiding this comment.
good point... which means the QueryParameters is likely just as wonky, I copy pasted it from that.
| if (path.length() > 1 && path.endsWith("/")) { | ||
| path = path.substring(0, path.length() - 1); | ||
| } | ||
| return SPA_ROUTES.contains(path) || path.matches("/user-roles/[A-Za-z0-9-]+"); |
There was a problem hiding this comment.
Going to open an issue. You're correct, but there's already enough change in this PR, even if this is small.
| + " implemented")}, | ||
| description = "Returns Projects Data", | ||
| tags = {TAG}) | ||
| tags = {TAG}, path = "/project") |
|
|
||
|
|
||
|
|
||
| //TODO: The rest |
There was a problem hiding this comment.
Still figuring that out. I did get the scheme processor working,
but the returned OpenAPI object is now a builder from javalin-openapi that doesn't behave the same way... plus most of what we were doing here can no be moved to the controllers, like examples.
so I might decide to let those go for this PR, and then come back and do a follow up on them. As much as I want it all to work. at a minimum if this gets merged into main it needs to work for existing usage. And there's already new work that not going to be super trivial to rebase into this.
| dsConfig.setJdbcUrl(ConfigVariables.getConfigString("CDA_JDBC_URL")); | ||
| dsConfig.setUsername(ConfigVariables.getConfigString("CDA_JDBC_USERNAME")); | ||
| dsConfig.setPassword(ConfigVariables.getConfigString("CDA_JDBC_PASSWORD")); | ||
| dsConfig.setMaximumPoolSize(ConfigVariables.getConfigInt("CDA_POOL_MAX_ACTIVE", 1)); |
There was a problem hiding this comment.
Yeah, I'm kinda assuming if those aren't set it's a test environment but that should likely be a different value with the integration tests specifying the 1.
I'll go with 10. I suspect most devs that would run CDA directly that will be testing something won't necessarily be testing pool issues but trying to do some bulk work.
| public CwmsDataApi build() | ||
| { | ||
| if (sessionManager == null) { | ||
| this.sessionManager = new SessionHandler(); |
There was a problem hiding this comment.
Yeah, that's a good idea.
Co-authored-by: Mike Neilson <gamingmike@gmail.com>
|
Will attempt rebase from main tomorrow. The conflicts shouldn't be difficult to fix though. |
| tags = UserListController.TAG | ||
| methods = HttpMethod.DELETE, | ||
| tags = UserListController.TAG, | ||
| path = "/users/list/{" + USER_LIST_ID + "}/members/{" + USER_ID + "}" |
There was a problem hiding this comment.
Not saying this is wrong its just curious that we have 3 controllers, one at /users/list/ and /user/list/{blah} and /user/list
| tags = TAG | ||
| methods = HttpMethod.POST, | ||
| tags = TAG, | ||
| path = "/forecast-spec" |
There was a problem hiding this comment.
This class has a variety of paths /forecast-spec /forecasts-spec/{} /forecasts-spec and /forecasts/spec we have a number of other controllers with inconsistencies.
| ContentType contentType = Formats.parseHeader(formatHeader, WaterUser.class); | ||
| ctx.contentType(contentType.toString()); | ||
| WaterUser user = Formats.parseContent(contentType, ctx.body(), WaterUser.class); | ||
| if (!projectId.equals(user.getProjectId().getName())) { |
There was a problem hiding this comment.
I wonder if case-sensitive matters?
| method = HttpMethod.GET, | ||
| path = "/locations/with-kind", | ||
| methods = HttpMethod.GET, | ||
| path = "/locations/with-kinds", |
There was a problem hiding this comment.
not sure if this was supposed to change from with-kind to with-kinds . If so, fine.
| int lastSlash = path.lastIndexOf('/'); | ||
| String pathWithOffice = path.substring(0, lastSlash) + format("/{%s}", OFFICE) + path.substring(lastSlash); | ||
| return format("/v2/" + pathWithOffice, args); | ||
| return format("/v2" + pathWithOffice, args); |
There was a problem hiding this comment.
Is this change intentional? /v2 vs /v2/ ?
|
I made it one time thru all the changed files and made comments on all the obvious things that I saw. There are a number of inconsistencies with how controllers are registered. I didn't check whether the controllers were already like that or if they are new changes but if they are new than I expect the integration tests won't be passing. Once the integration tests pass I think this will be ready |
Summary
Move to latest javalin (7.2.3)
Remove Use of Tomcat, no Tomcat 11+ in our local environment so will just use Javalin's default jetty and package it up.
NOTE: Due to Javalin updating the annotation plugin (this happened in javalin 5) this is going to be a large change as it touches every file and will need to alter how the OpenAPI static test works.
TODO:
Related Issue
Validation
Existing integration tests
Checklist