Consider "unwrap()/isWrapperFor()" method

[ttddyy]

In JDBC,Wrapper interface is implemented(extended) by other interfaces in order to allow user to retrieve specific implementation.

Since SPI is defines as interface, user might need to work on actual implementation instances. Especially this is true when instance is wrapped by delegation or proxy.

[mp911de]

What is the use case for unwrapping besides usage of API extensions (such as PostgresStatement)?

Is unwrapping really required or is unwrapping a consequence that drivers do not model their API extensions as an interface?

[gregturn]

Why does someone outside the scope of proxying need to see in?

Seems easier to let those corner cases actually cope with proxies rather than altering the core SPI for something that might actually be YAGNI.

[ttddyy]

So, one of the usecase is spring-boot autoconfiguration.

Let's say, postgres client-factory has jmx attributes specific to postgres.
In order to auto-register the jmx bean, autoconfiguration needs to introspect the bean(client-factory) whether it can be casted to the postgres client-factory.
If this is a wrapped(proxy or delegated) bean, there is no way to introspect the bean.
This is where unwrap will be used.

[gregturn]

Spring Framework itself has proxy utility methods to both probe and “unwrap” a proxy and get to the core bean.

[ttddyy]

Yes, I understand that since I recently made this PR.
spring-projects/spring-boot#15206
This is the use case I described above :)

However, if the bean is wrapped by non-spring, then spring aop framework cannot unwrap/extract it.

[mp911de]

Thanks a lot for the details. If we would add a wrapping aspect to R2DBC SPI, I would advise to place it in a less prominent way than JDBC does. JDBC includes unwrapping methods in a lot of their interfaces which is sort of cluttering the API.

How about just providing an additional interface that can be picked up by wrapping/proxying libraries and libraries that are interested in unwrapping in a non-invasive way?

We could provide

interface Wrapped {
    Object unwrap();
}

as a standalone interface. Proxies would implement that interface and give access to the underlying object. We provide a minimal API to allow unwrapping and I think unwrapping should be an edge-case anyway and not the regular thing that is used by regular client code.

Thoughts?

[ttddyy]

This approach sounds good to me.
It doesn't clutter existing SPIs.

It is wrapper's responsibility to implement(or respond) the unwrap() call.
In my datasource-proxy-r2dbc, ProxyObject does same, and similar in Advised#getTargetSource in spring.

When it comes to unwrapping time, it is a bit of more code to find the target one:

Class<?> targetClass = ...;  // class that I'm looking for

while(true) {

  if(targetClass.isInstance(candidate)) {
    return candidate;  // found
  } else if(candidate == null) {
    return null;  // not found
  }

  if(candidate instanceof Wrapped) {
    candidate = ((Wrapped)candidate).unwrap();
  } else {
    candidate = null;  // cannot unwrap
  }
}

I agree unwrapping is not a major use case; so it should be ok to let unwrapper write code like this to find the target. Rather, making SPI non invasive has bigger benefit.

[mp911de]

Care to submit a pull request?

[ttddyy]

sure, will do tomorrow. :)

[ttddyy]

Thinking bit more about the usage, I think there are two use cases:

1. simply I want to unwrap and get the original object
2. I want to unwrap to a specific class which might be wrapped multiple times.

For use case 1, this can be done by current API:

Object unwrap();

For the second use case, it can be done by the for-loop I commented above, or having this method:

<T> T unwrap(Class<T> targetClass);

In my opinion, I think we do NOT implement the second usecase for now. It can be achieved by first use case with for-loop. Later IF there is a requirement to this, then may consider adding it for simplicity.

Another thing, during the meeting call, there was a mention of generics.

In JDBC, it is NOT restricting unwrap() to be bound to the wrapper class type.
For example, the above mentioned spring-boot usecase, it is unwrapping/extracting DataSourceProxy object from DataSource, however DataSourceProxy does NOT implement DataSource interface.
It's very much a corner case. However, it may be good to be aware of it.

So, if we want to add a generics, maybe it would be like this:

<T> T unwrap();

Since this is an unchecked type cast(it expects the receiver's type), I think it's not be recommended for SPI.