Tags: google/nomulus
Tags
Migrate core, billing, and history to java.time (#3020) Migrated core entity primitives (GracePeriod, RegistryLock, TimeOfYear), transfer objects (BaseTransferObject, DomainTransferData, TransferResponse), and HostBase from Joda-Time DateTime to java.time.Instant as Phases 5 and 7. Migrated the Billing Ecosystem (BillingBase, BillingEvent, BillingRecurrence, BillingCancellation) and associated Beam pipelines (ExpandBillingRecurrencesPipeline, InvoicingPipeline) to java.time.Instant as Phase 6. Migrated PollMessage event times and all associated Poll flow utilities (PollAckFlow, PollRequestFlow) to use Instant natively. Migrated core timestamp tracking on EppResource (creationTime, lastEppUpdateTime, deletionTime) as well as CreateAutoTimestamp and UpdateAutoTimestamp to Instant, shedding deprecated DateTime accessors. Migrated the entire HistoryEntry reporting ecosystem (HistoryEntry, DomainTransactionRecord, HistoryEntryDao) completely to java.time.Instant. Updated all associated EPP flows, tools, and testing helpers to handle Instants directly where supported.
Migrate core, billing, and history to java.time (#3020) Migrated core entity primitives (GracePeriod, RegistryLock, TimeOfYear), transfer objects (BaseTransferObject, DomainTransferData, TransferResponse), and HostBase from Joda-Time DateTime to java.time.Instant as Phases 5 and 7. Migrated the Billing Ecosystem (BillingBase, BillingEvent, BillingRecurrence, BillingCancellation) and associated Beam pipelines (ExpandBillingRecurrencesPipeline, InvoicingPipeline) to java.time.Instant as Phase 6. Migrated PollMessage event times and all associated Poll flow utilities (PollAckFlow, PollRequestFlow) to use Instant natively. Migrated core timestamp tracking on EppResource (creationTime, lastEppUpdateTime, deletionTime) as well as CreateAutoTimestamp and UpdateAutoTimestamp to Instant, shedding deprecated DateTime accessors. Migrated the entire HistoryEntry reporting ecosystem (HistoryEntry, DomainTransactionRecord, HistoryEntryDao) completely to java.time.Instant. Updated all associated EPP flows, tools, and testing helpers to handle Instants directly where supported.
Migrate TMCH, SMD, and Fee models to java.time (#3019) Continues the project-wide migration from Joda-Time's DateTime to java.time.Instant, focusing on Trademark Clearinghouse (TMCH), Signed Mark Data (SMD), and Fee extension models. Key updates: - TMCH & SMD: Updated SmdRevocationList and domain check/create flows to use Instant for sunrise validations and revocation checks. - Fee Extension Ecosystem: Refactored FeeCheckRequest, FeeCreateCommandExtension, and BaseFee to use Instant for effective dates and period calculations. - EPP Objects: Updated DomainInfoData, TransferResponse, and PollMessage objects to use Instant for event timestamps. - Pricing Logic: DomainPricingLogic methods now accept Instant for cost calculations. Additionally, DateTimeUtils was enhanced with Instant compatibility methods for plusMonths and minusMonths to safely handle leap years. Redundant conversions between DateTime and Instant were eliminated throughout the flows and tests. DomainFlowUtils leverages Instant natively to avoid inline casting, and test assertions now utilize Truth's Instant subjects for cleaner validation.
Fix XML parsing issues that occur on dependency update (#3012) We want to make sure that we use the same XML factories no matter what, so we use "newDefaultFactory" instead of "newFactory" (to avoid picking up some random thing on the classpath). This also fixes an exception that occurs if you haven't synced the internal repo with the public repo.
Fix XML parsing issues that occur on dependency update (#3012) We want to make sure that we use the same XML factories no matter what, so we use "newDefaultFactory" instead of "newFactory" (to avoid picking up some random thing on the classpath). This also fixes an exception that occurs if you haven't synced the internal repo with the public repo.
Fix XML parsing issues that occur on dependency update (#3012) We want to make sure that we use the same XML factories no matter what, so we use "newDefaultFactory" instead of "newFactory" (to avoid picking up some random thing on the classpath). This also fixes an exception that occurs if you haven't synced the internal repo with the public repo.
Fix XML parsing issues that occur on dependency update (#3012) We want to make sure that we use the same XML factories no matter what, so we use "newDefaultFactory" instead of "newFactory" (to avoid picking up some random thing on the classpath). This also fixes an exception that occurs if you haven't synced the internal repo with the public repo.
PreviousNext