The constructors are being called, but absent an explicit call the one being called is the parameter-less one.

and because the parameterless one is called 'e' is null and we skip the instatiation. Just stripping the =nullptr bit out causes the compile to fail.

Otr maybe I've missed your point. Bottom libne: we have other types of hell to worry about right now so lets come back to this later

We definitely should revisit some of this design because the inheritance isn't working the way I thought it did. Non-virtual subclasses seem to all need to explicitly call the c'tor, but there must be a collapsing by the compiler because of the virtual inheritance above. I would have expected that calling the c'tor from the OpenSAML class would fix this, but it doesn't get called by the SP's version unless that's also fixed.

I'll clone the bug so there's a record of both fixes.

My assumption was the default c'tor is there to allow the virtual inheritance to work, but that may be incorrect. I was planning to try it regardless, and I'd probably make the change immediately simply because of the risk of this.

I was also planning to think through whether it makes sense to add warnings in cases where no filters are installed, but I don't know how if that's practical. Obviously the top priority is to get the patch out fast.

Couple of points here

• I have an indirect fix for this locally checked in (in a completely revamped SP DynamicMetadataProvider).  I wasn't going to push this anyway, but I'll make sure I don't (not if I get to it the fix in the yet-to-be-written LocalDynamicMetadatProviser in opensaml.

• More relevantly, is it worth changing (in 3.0) the signature of the MetadatProvider to not have the zero parameter constructor.  This will then detect this at compile time (at the cost of an API change and maybe a change to some (test?) code.