Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ProcessingEnvOptionsHolder not initialized yet on reverse mapping #232

Open
clehene opened this issue Aug 21, 2022 · 5 comments
Open

ProcessingEnvOptionsHolder not initialized yet on reverse mapping #232

clehene opened this issue Aug 21, 2022 · 5 comments
Labels
more info requested More info from reported needed

Comments

@clehene
Copy link

clehene commented Aug 21, 2022

Internal error in the mapping processor: java.lang.IllegalStateException: ProcessingEnvOptionsHolder not initialized yet.

ProtobufEntity mapFromDto(Entity entity);

// causes Internal error in the mapping processor: java.lang.IllegalStateException: ProcessingEnvOptionsHolder not initialized yet.
// with or without the inverse annotation
@InheritInverseConfiguration
Entity mapToDto(ProtobufEntity message);
@seime
Copy link
Contributor

seime commented Sep 8, 2022

@ro0sterjam I think this is related to #133 - do you have any insight?

@clehene Please provide more details

@seime seime added the more info requested More info from reported needed label Oct 13, 2022
@v-chernyshev
Copy link

I see the same problem when the Maven annotation processor configuration contains these elements:

<path>
  <groupId>org.mapstruct</groupId>
  <artifactId>mapstruct-processor</artifactId>
  <version>${mapstruct.version}</version>
</path>
<path>
  <groupId>no.entur.mapstruct.spi</groupId>
  <artifactId>protobuf-spi-impl</artifactId>
  <version>${protobuf-spi.version}</version>
</path>

The error trace when I try to map an enum is:

error: Internal error in the mapping processor: java.lang.IllegalStateException: ProcessingEnvOptionsHolder not initialized yet.
    at no.entur.mapstruct.spi.protobuf.ProcessingEnvOptionsHolder.containsKey(ProcessingEnvOptionsHolder.java:69)
    at no.entur.mapstruct.spi.protobuf.ProtobufEnumMappingStrategy.initEnumPostfixOverrides(ProtobufEnumMappingStrategy.java:69)
    at no.entur.mapstruct.spi.protobuf.ProtobufEnumMappingStrategy.getEnumPostfix(ProtobufEnumMappingStrategy.java:59)
    at no.entur.mapstruct.spi.protobuf.ProtobufEnumMappingStrategy.isMapEnumConstantToNull(ProtobufEnumMappingStrategy.java:88)
    at no.entur.mapstruct.spi.protobuf.ProtobufEnumMappingStrategy.getEnumConstant(ProtobufEnumMappingStrategy.java:113)
    at org.mapstruct.ap.internal.model.ValueMappingMethod$Builder.getEnumConstant(ValueMappingMethod.java:316)
    at org.mapstruct.ap.internal.model.ValueMappingMethod$Builder.enumToEnumMapping(ValueMappingMethod.java:209)
    at org.mapstruct.ap.internal.model.ValueMappingMethod$Builder.build(ValueMappingMethod.java:103)

As far as I can see, MapStruct finds the SPI implementations, but the "fake" ProcessingEnvOptionsHolder annotation processor is never initialised.

@ro0sterjam
Copy link
Contributor

Hey folks, apologies for the late response.

After digging into it, it seems that the order of the processors ProcessingEnvOptionsHolder and org.mapstruct.ap.MappingProcessor are run in an incompatible order. The latter depends on the former so when the former is not run first then you end up in this situation.

After doing some more research though, it seems like AnnotationProcessors really should not depend on each other, as the order is not guaranteed.

That said, it seems to only be a problem on my local computer if mapstruct-processor is defined before protobuf-spi-impl. Reversing that order seems to fix the issue.

<path>
  <groupId>no.entur.mapstruct.spi</groupId>
  <artifactId>protobuf-spi-impl</artifactId>
  <version>${protobuf-spi.version}</version>
</path>
<path>
  <groupId>org.mapstruct</groupId>
  <artifactId>mapstruct-processor</artifactId>
  <version>${mapstruct.version}</version>
</path>

Maybe that would work for you as well.

At the end of the day though, this is definitely too fragile. Full disclosure, my team has moved away from using this library, so if so desired, the easiest path of resolution would probably to just revert my commits. Otherwise, I can take some time to see if I'm able to fix forward. In the meantime, could you try reordering the dependency definitions and report back if that works as a work around?

@ro0sterjam
Copy link
Contributor

ro0sterjam commented Oct 26, 2022

Digging in further, the classes that MapStruct surfaces for overriding do not have the ProcessingEnvironment.getOptions() value passed through so there is no way to access the compilerArgs.

My original method of having a separate AnnotationProcessor fetch these compilerArgs appears to be an anti-pattern as the processors should operate in isolation from one another.

The feature to properly configure an SPI should be released with 1.6 of MapStruct so this functionality should be updated once released, as to not require the workaround.

ro0sterjam added a commit to ro0sterjam/mapstruct-spi-protobuf that referenced this issue Oct 26, 2022
@dtrunk90
Copy link

dtrunk90 commented Feb 9, 2024

Having the same issue in a legacy Ant based project without dependency management (simple jar files).

The workaround here looks like that:

<path id="my.class.path">
	<fileset dir="${libs.dir}" includes="*.jar">
		<!-- workaround, see https://github.com/entur/mapstruct-spi-protobuf/issues/232#issuecomment-1291493889 -->
		<exclude name="mapstruct-processor-*.jar" />
	</fileset>
	<fileset dir="${libs.dir}" includes="mapstruct-processor-*.jar" />
</path>

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
more info requested More info from reported needed
Projects
None yet
Development

No branches or pull requests

5 participants