TP bring-up: missing JAXB Atom marshaller, narrow component scan, and broader OAuth2-client wiring gaps #146

Summary

The Third Party module cannot complete Spring context initialization against the current dev-mysql profile. A narrow chain of bean-wiring gaps surfaces when bringing TP up locally against a fresh DC + AS pair (in support of #122 PR C4 manual testing). The deeper architectural issue is that TP is not currently a functional ESPI third party — its OAuth2 client config, Atom marshalling pipeline, and Notification Endpoint receiver path have not been brought to a working state in the Spring Boot 4 / Spring 7 migration.

Priority context: Per the project lead, DC API completion is upstream of this work. TP cannot meaningfully exercise the OAuth2 + ESPI resource flow without a complete DC API surface (the BatchList notifications, the Subscription resource feeds, the Customer/PII resource feeds, etc. that TP would receive). File a focused DC API audit/completion issue first; this TP issue should be triaged after DC stabilizes.

What's already been observed locally

Encountered in this order while running mvn spring-boot:run -Dspring-boot.run.profiles=dev-mysql:

1. Missing UsagePointMapper bean — TP's @SpringBootApplication.scanBasePackages excluded org.greenbuttonalliance.espi.common.mapper, so MapStruct-generated mapper impls were not registered. Half-fix in PR Phase 2.0 — Stand up auth-server in dev with opaque tokens + subscription-bound introspection (Phase 2 precursor) #122 PR C4 (broadened scan to org.greenbuttonalliance.espi.common).

2. Missing EspiIdGeneratorService bean — same root cause; lives in org.greenbuttonalliance.espi.common.service (not .service.impl). Resolved by the same scan broadening in PR C4.

3. Missing Jaxb2Marshaller bean named atomMarshaller — ResourceRESTRepositoryImpl (and several other resource repos) @Autowired a @Qualifier("atomMarshaller") Jaxb2Marshaller. No @Bean definition currently exists for it in TP, openespi-common, or any autoconfiguration on the classpath. PR C4 does NOT fix this — manual testing stops here.

What likely remains under the surface

The pattern above (TP discovering missing collaborator beans one-at-a-time during context init) suggests the migration from the pre-Spring-Boot-4 codebase left TP partially wired. Likely items to audit:

• Atom feed marshalling pipeline — Jaxb2Marshaller + ESPI/Atom JAXB context configuration, currently undefined.
• Notification Endpoint — TP's REST endpoint that receives BatchList from DC at grant-completion. Status: unverified, likely also missing security + Jaxb plumbing.
• OAuth2 client config — TP's application.yml references client-id: third_party and callback URIs; needs end-to-end verification against AS's current RegisteredClient definition (AuthorizationServerConfig.java:278-301).
• Resource fetching layer — ResourceRESTRepositoryImpl, UsagePointRESTRepositoryImpl, etc.; whether they actually round-trip against DC's current Atom feed endpoints.
• JPA layer — TP has 24 repository interfaces; need to confirm the entity scan and database schema (TP currently runs with flyway: 0 migrations against a thirdparty MySQL DB, suggesting either it's relying on Hibernate ddl-auto=update or it doesn't actually persist anything that matters yet).

Reproduction (current state)

# Per PR C4 README instructions
cd openespi-thirdparty
mvn spring-boot:run -Dspring-boot.run.profiles=dev-mysql

Fails with:

APPLICATION FAILED TO START
Field marshaller in org.greenbuttonalliance.espi.thirdparty.repository.impl.ResourceRESTRepositoryImpl
required a bean of type 'org.springframework.oxm.jaxb.Jaxb2Marshaller' that could not be found.
The injection point has the following annotations:
  - @org.springframework.beans.factory.annotation.Autowired(required=true)
  - @org.springframework.beans.factory.annotation.Qualifier("atomMarshaller")

Recommended approach (after DC API work lands)

1. Audit the full TP bean dependency graph at context-init time — identify every @Autowired collaborator from TP code into openespi-common and confirm each has a definition path. Don't fix one-at-a-time; produce a list, then plan.
2. Define the missing atomMarshaller Jaxb2Marshaller bean — likely belongs in either openespi-common's Spring config or a new TP @Configuration class. Aligns with whatever JAXB context the existing BaseExportService family uses on DC.
3. End-to-end smoke the OAuth2 customer flow: TP root → AS /oauth2/authorize → DC consent screen → token exchange → TP fetches a UsagePoint feed. (Blocked on the DC API completion above.)
4. Notification Endpoint smoke test — DC pushes a BatchList to TP at grant-completion; TP processes and persists. (Likely also blocked on DC.)
5. Remove PR Phase 2.0 — Stand up auth-server in dev with opaque tokens + subscription-bound introspection (Phase 2 precursor) #122 PR C4's TP scan-broadening workaround once the proper wiring is in place — or keep it as the canonical wide-scan pattern if that matches the project's preference.

Out of scope for this issue

• DC API completion + missing endpoints — upstream of this work, needs its own focused issue and probably its own multi-PR effort.
• The PR C4 work itself (Phase 2.0 — Stand up auth-server in dev with opaque tokens + subscription-bound introspection (Phase 2 precursor) #122) — already shipped, ships its workaround for the two minimal bean-wiring gaps so AS can be tested manually.
• Issue Complete #123 schema-repair sync: align AS V1 schema with application code column names #145 (AS schema-repair sync) — independent of TP.

Acceptance

• Document the architectural intent for TP (is it a reference OAuth2 client for ESPI integrators? a development harness for DC API testing? something else?).
• mvn spring-boot:run -Dspring-boot.run.profiles=dev-mysql boots TP cleanly against a working DC + AS.
• Browser flow: TP root → OAuth2 authorize → DC screens → token exchange → TP can fetch and render at least one ESPI resource.
• DC-to-TP Notification Endpoint receives and processes a BatchList push.
• PR Phase 2.0 — Stand up auth-server in dev with opaque tokens + subscription-bound introspection (Phase 2 precursor) #122 PR C4's TP scan-broadening workaround is either confirmed correct and kept, or replaced with the project's preferred pattern.