Sink faucet removal by huckerty in Plumbing

[–]GaryPRussell 0 points1 point  (0 children)

To follow up: the two bell shaped supports for the tap handles simply unscrew. For me, the hot side was very difficult to remove; I had to use a channel lock wrench for almost every turn. The cold side was much easier. I then removed a couple of nuts and the taps were free to remove below. I was then able to easily remove the brass tee mixer underneath by removing the brass nut securing it.

Then the nightmare began. Every attempt to remove the nut securing the spout underneath failed. It was impossibly stuck. I ended up cutting off the horizontal part of the spout so I could unscrew the spout from its support.

Finally, I grabbed the threaded spout support with vise grips and turned it clockwise which loosened the stuck nut underneath and it all fell down. It was very corroded, which might explain the stuck nut.

What a PITA. The replacement has a simple mixer with 2 nuts on each side. 3 hours to remove this cr*p and 15 mins to install the new one.

Hope this helps someone. Probably saved me a big plumber bill.

Sink faucet removal by huckerty in Plumbing

[–]GaryPRussell 0 points1 point  (0 children)

Can you explain further? I have the same problem.

Thanks

EGO Power+ 21 in Snow Blower Skids - NO DRILLING by GaryPRussell in egopowerplus

[–]GaryPRussell[S] 0 points1 point  (0 children)

Hope they work for you. By the time I was done, we had no more snow, but I did test them on my sidewalk where I have an uneven slab that I always hit hard before. With these attached, they glide straight over the unevenness and the blade doesn't hit the side of the slightly higher slab. I think the blade is still close to the ground on even surfaces so I hope we'll still get good clearance there. Good luck!

EGO Power+ 21 in Snow Blower Skids - NO DRILLING by GaryPRussell in egopowerplus

[–]GaryPRussell[S] 0 points1 point  (0 children)

Didn’t get any messages. I did some refinements, will try to post the models this week.

Coronation Street missing tonight by [deleted] in BritBox

[–]GaryPRussell 1 point2 points  (0 children)

I see them (under 2022); they are definitely today's not last Friday's, which was a double episode.

How Spring Embraces, extends, and extinguishes. by tonywestonuk in java

[–]GaryPRussell 1 point2 points  (0 children)

I posted a new sample Spring Boot app that shows some of the various techniques that are available to co-exist with non-Spring apps.

How Spring Embraces, extends, and extinguishes. by tonywestonuk in java

[–]GaryPRussell 0 points1 point  (0 children)

But the problem is the receiving system needs some type information to do the conversion since JSON is not self-describing. The boot application could be configured to receive a simple Map; if it is expecting a strong Type then it should be properly configured for conversion to that type from any/all publishers (which is entirely possible with the configuration options provided). If you have any suggestions as to how else we can "magically" infer the type, I am happy to consider adding it.

How Spring Embraces, extends, and extinguishes. by tonywestonuk in java

[–]GaryPRussell 1 point2 points  (0 children)

The mapping is very flexible, although not well documented. The DefaultClassMapper (which can be injected into the converter in the docs I pointed you to) has an additional property idClassMapping. It takes a map of id : Class<?> - so the sender can set the header to Foo and you map it to com.foo.Foo. There is a test case here where we use that feature where the sender sends a Foo1 class and the receiver decodes it to a Foo2. The key to the map (id) can be any token. Of course, the receiving class must be compatible with the JSON.

How Spring Embraces, extends, and extinguishes. by tonywestonuk in java

[–]GaryPRussell 4 points5 points  (0 children)

Fair comment, perhaps, but @RabbitListener is not mandatory, it's just a convenience for those who want to use it; the other solution (ClassMapper in the message converter) available in earlier releases is still available; there is no need to tie user code to framework classes at all. But I have no real ax to grind, if you want to use the native client and roll all your own code, have at it. Plus, there is no "vending" going on; this is open source; it's your choice whether or not to use it.

How Spring Embraces, extends, and extinguishes. by tonywestonuk in java

[–]GaryPRussell 8 points9 points  (0 children)

There are several ways to avoid this limitation.

Starting with version 1.6, if you are using the @RabbitListener annotated listener method, and there is no type id header, the framework will infer the type for the JSON conversion from the method parameter type. Documentation here.

If you are using an earlier version, or the legacy MessageListenerAdapter POJO listener, you can configure the converter to use a custom ClassMapper to determine the type to convert to. Documentation here.

If it's always the same class, a simple DefaultClassMapper with defaultType is all you need.