novaris-common-legacy

Geteilte Bausteine, die von mehreren Novaris-Teilsystemen verwendet werden - bewusst als eigenes, sehr kleines Modul gehalten, damit z.B. novaris-billing-soap (Server) und novaris-policy-core (Client) exakt denselben SOAP-Vertrag verwenden, statt ihn zu duplizieren.

Inhalt

Paket	Inhalt
`common.jndi`	`JndiNames` (zentrale JNDI-Namenskonstanten), `JndiLookupHelper` (Lookup-Wrapper fuer nicht container-verwaltete Aufrufer)
`common.exception`	`LegacySystemUnavailableException` - die projektweite System-Exception (siehe `docs/10-ejb-konzepte/06-exceptions.md`)
`common.messaging.dto`	JMS-Payload-Klassen: `ClaimNotificationMessage`, `ClaimProcessingResult`, `PolicyEventMessage`, `PolicyEventTypes`
`common.billing.contract`	Der SOAP-Vertrag des Billing-Systems (`BillingServicePort`, `BillingRegistrationFault`, `BillingFaultDetail`, `BillingServiceLocations`) - siehe `docs/20-soap/`

Bauen

# aus novaris-legacy-parent/:
mvn -pl novaris-common-legacy install

Reine Bibliothek ohne eigene Tests - die Klassen hier werden ueber die Tests der Module geprueft, die sie tatsaechlich verwenden (novaris-policy-core, novaris-billing-soap, novaris-claims-mq, novaris-notification-jms).

Warum das ueberhaupt ein eigenes Modul ist

Siehe docs/10-ejb-konzepte/07-jndi-und-packaging.md und docs/20-soap/01-contract-first-und-wsdl.md - Kurzfassung: ein SOAP-/JMS-Vertrag muss auf beiden Seiten (Server und Client) exakt dieselbe Java-Klasse sein, sonst funktioniert weder die (de-)serialisierte Marshalling-Kompatibilitaet noch die Message-Selektor-Filterung zuverlaessig.

⌂ Cockpit