Perhaps InputstreamRepeatableAccess would be a better name for this ...
I also wonder about what to do (if anything) with that chunk of memory the byte[] occupies, once this repeatable access is no longer needed; should there be some mechanism to release this?

Hey @jrenaat 👋🏻 😃

I remembered that we have something for XML validation in Validator code here: https://github.com/hibernate/hibernate-validator/blob/b14c620a3f7d93a322fa122b52e1b9e83c376c35/engine/src/main/java/org/hibernate/validator/internal/xml/mapping/MappingXmlParser.java#L98-L143

you'll see that that code relies on InputStream#mark()/InputStream#reset() instead of keeping all the file. And the way we make sure that these methods are "supported" by the stream is here:
https://github.com/hibernate/hibernate-validator/blob/b14c620a3f7d93a322fa122b52e1b9e83c376c35/engine/src/main/java/org/hibernate/validator/internal/engine/AbstractConfigurationImpl.java#L287

IDK if that would be applicable here or not, but I thought I'd let you know about it, and you can then decide 😃.

Thanks for the pointers. I did consider the mark/reset approach but i'm not 100% it would work in our case, i think we actually need 2 separate inputstreams.

Really not a fan of storing this as an inst var here. As an illustration of why, the only use of it actually does not even check whether it is null prior to using it even though only 1 of the 2 exposed methods actually sets it (and then only in 1 of the 2 impls).

I think we need to think about a way to not store this as an inst var, especially here.

Pass it as a parameter to the doBind methods?

I don't think that's great either. Basically there are 2 forms of bind here - one accepting a Source and one accepting a InputStream(Access).

Possibly having our XMLEventReader impls have a way to reset or rebuild themselves?

Maybe we say we don't care about this for the Source forms...

As far as I can see, there are 2 places where the Source form comes into play and I think neither is a real problem:

1. org.hibernate.boot.jaxb.internal.XmlSources#fromDocument wraps the DOM document as a Source. We no longer use this XmlSources#fromDocument method (as we no longer support DOM) and since its internal we could deprecate or even remove it.
2. org.hibernate.jpa.boot.spi.PersistenceXmlParser#loadUrlWithJaxb which is loading configuration and chooses to wrap an InputStream as a StreamSource to pass to the binder. But (a) we could instead wrap it as a InputStreamAccess and (b) we don't really care about strict validation for configuration files.

So maybe a better holostic strategy here is to:

1. Deprecate Binder#bind(Source, Origin)
2. Remove XmlSources#fromDocument (its internal and we do not use it)
3. Change PersistenceXmlParser#loadUrlWithJaxb to pass the InputStream(Access)
4. Change AbstractBinder#createReader to return a XMLEventReader whihc provides access to the underlying InputStreamAccess. In the (now deprecated) cases that a Source was used, that reader would just throw an exception.

wdyt?

One other thing... you changed the signature of Binder#bind(InputStream,Origin) to Binder#bind(InputStreamAccess,Origin). Technically Binder is an SPI and we really ought to not be changing that.

However, we could deprecate the old form in favor of a new one with that signature, the old form just wrapping the passed InputStream as an InputStreamAccess and calling the new form.