JSONSerialize and JSONDeserialize with Lombok custom deserialization builders

I was in a situation where I was using both Lombok and Jackson to manage some Java objects being serialized and deserialized.

My objects were declared in this format:

@Builder(toBuilder = true)
@JsonDeserialize(MyClass.MyClassBuilder.class)
@Dataclass MyClass {

    @JsonFormat(shape = JsonFormat.Shape.STRING, pattern = "yyyyMMdd")
    @JsonSerialize(using = LocalDateSerializer.class)
    @JsonDeserialize(using = LocalDateDeserializer.class)
    LocalDate myDate;

    @JsonPOJOBuilder(withPrefix = "")
    public static final class MyClassBuilder {

    }
}

I would run deserialization using a regular JSON ObjectMapper instance against a JSON object of the form:
{ "myDate": "20181207"}

 and get an error that looked something like:

com.fasterxml.jackson.databind.JsonMappingException: Can not construct instance of java.time.LocalDate: no String-argument constructor/factory method to deserialize from String value ('20181207')

Some searching made me hypothesize that this was due to the fact that I'm doing my deserialization using a builder, and that the annotations were being ignored.  I changed the code as follows and it began to deserialize properly:

@Builder(toBuilder = true)
@JsonDeserialize(MyClass.MyClassBuilder.class)
@Dataclass MyClass {
    
    LocalDate myDate;

    @JsonPOJOBuilder(withPrefix = "")
    public static final class MyClassBuilder {
        
        @JsonFormat(shape = JsonFormat.Shape.STRING, pattern = "yyyyMMdd")
        @JsonSerialize(using = LocalDateSerializer.class)
        @JsonDeserialize(using = LocalDateDeserializer.class)
        LocalDate myDate;
    }
}

 

Postgres 9.5 to 9.6 JSON generation errors

I experienced an odd error at a client when I was trying to duplicate their database to a local Dockerized Postgres instance. I used clkao/postgres-plv8 as my baseline since the client had JS in their PLPGSQL. They have a complex series of queries and views that produce JSON output, and we're converting that to be done in Java instead.

The problems came when I ran the view that generated the JSON on my machine versus on their dev environment, from which I had taken a dump minutes before. I got completely different answers for the JSON, not just object ordering but objects in the wrong places. I downgraded to clkao/postgres-plv8:9.5-2.0 to be closer to the 9.5.2 version of Postgres the client was running and the problem went away.

I don't know what caused the difference in JSON output between Postgres 9.5 and 9.6 running the same views and procedures, but it's something to watch out for.

Server-Side Includes, Apache, and Subversion: svn: E200014: Checksum mismatch

If you look up the checksum mismatch error in the title, you'll get lots of advice about how to modify your working copy, fix your local checksum in svn/entries, and so on. Sometimes, however, that's not your issue.

If you're getting a checksum mismatch when checking out a .shtml file or some other file and it can't be explained by a problem with the working copy (say, for instance you haven't checked the file out yet), then try the following:

svn cat https://your-server.com/path/to/file

If you get a message of the form

[an error occurred while processing this directive]

then you should check your Subversion server's settings. If it is allowing includes:

Options Includes

then you will want to turn that off for the Subversion directory/location paths you're serving. This will cause Apache to leave them alone and serve them like any other files. This also alleviates a potential security issue, as one could imagine a malicious user checking in .shtml files to cause operations to happen on your server in unexpected ways.

Revenge of the undefined method `users_url' for #<DeviseCustom::RegistrationsController:

I ran into this problem again when I had a secondary object that I was trying to save along with a Devise user at registration/sign-up. I copied the entire create method so that the secondary object could prevent the Devise user from saving if it had an error. However, when I put that logic in and the user didn't save, I got the title error above.

The problem is that Devise's internal magic gets confused if the user isn't persisted but doesn't have any errors. The solution is to apply an error to resource.errors[:base], where resource is the Devise user.

undefined method `user_url' for #<DeviseCustom::RegistrationsController:

I ran into this error when trying to work on a user profile edit page that used Devise.

The error is actually a red herring; what it means is that your update of the user failed or didn't do what you expected, and it's trying to fall back to a default page.

Take a look at your user save methods and callbacks and confirm that the user method is doing what you expect. In my particular case, I had a before_validation callback that set a field on the user that happened to be false. The callback returned that false and mistakenly interpreted it as a failure. So I had to explicitly return true to indicate that the method succeeded.

internal error (got unexpected object kind 'commit')

Trac's Git plugin will sometimes produce error messages on submodules or other obscure Git structures, reporting:

"internal error (got unexpected object kind 'commit')"

when you attempt to browse them. It's suspected this is due to Git submodules.

We fixed this by manually applying this patch to the 0.11 version of the plugin:

http://trac-hacks.org/attachment/ticket/3104/gitplugin.diff

I've also added an image of it here, just in case the web site goes away.

No such file or directory: mod_wsgi (pid=[redacted]): Unable to connect to WSGI daemon process '[redacted]' on '/var/run/wsgi.[redacted].sock'

I ran into a problem recently where my customers were unable to access their Trac instances, which we serve via mod_wsgi, without receiving a 503 error. Under the hood, we saw an error of the form:

No such file or directory: mod_wsgi (pid=[redacted]): Unable to connect to WSGI daemon process '[redacted]' on '/var/run/wsgi.[redacted].sock'

The socket is made up of 3 numbers, so if you see a socket of the form /var/run/wsgi/1.2.3.sock, 1 refers to the server process that spawned it, 2 refers to the ap_my_generation setting (a number related to gracefuls), and the 3 is an entry_id, which I don't know about because I didn't have to.

I concluded that Apache was essentially saying to mod_wsgi, "You promised there would be a socket at this place we agreed on, and there's not." mod_wsgi is no longer serving sockets there because it has been respawned by a new child process.

Using the socket number, I was able to determine that there was a stray httpd process that should have died many gracefuls ago, but did not. We graceful dozens of times per day to accommodate the changes on the server, so it's unsurprising one would occasionally get dropped. In our case, the immediate solution was to kill the process mentioned in the socket number (1 in the example above). At that time, the problem went away.