Arndt Schönbergs Weblog

Samstag Jan 12, 2019

Maven Build Fehler: The site descriptor cannot be resolved from the repository

Wir sind bei uns kürzlich von Nexus 2 auf Nexus 3 gewechselt. Nach dem Import der Artefakte starteten wir einen Build und erhielten bei alle Projekten den Fehler

 
   The site descriptor cannot be resolved from the repository:
  ArtifactResolutionException: Unable to locate site descriptor: Could not transfer artifact de.schoeso.poms:XXXXX:xml:site_en:1.1.2 from/to snapshots
Wir haben nicht mehr im Detail nachgeforscht warum der Unterschied zwischen Nexus Version 2 und 3 bei uns aufgetreten ist (möglich Gründe können bei Nexus liegen oder beim sauberem Reimport der Artefakte). Ursache für den Fehler ist jedoch das maven-site-plugin. Dieses erwartet, wenn nichts anderes konfiguriert ist, das für übergeordnete Artefakte im Repository downloads für Sites bereitstehen (site_en). Bei uns sind Parent-Poms an dieser Stelle aber nur strukturierende POMs die einheitliche Einstellungen konfigurieren. Es sind als keine Projekte und eine Datei
 
   site.xml
besitzen sie aus diesem Grund auch nicht.

Lösung

Die Lösung ist es die "Ableitung" der Seiten zu unterbinden. Hierfür muss in der site.xml das Attribut combine.self auf override gesetzt werden (dies Attribut steht nicht seit Anfang der xml Definition zur Verfügung, also ggf auf die aktuelle Version - hier 1.6.0 - wechseln)
 
<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/DECORATION/1.6.0"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://maven.apache.org/DECORATION/1.6.0 http://maven.apache.org/xsd/decoration-1.6.0.xsd"
         combine.self="override"
         name="schöso baseClassesJunit">
</pre>
Des Weiteren muss sichergestellt werden, dass das pom für das maven-site-plugin auf dieses Verzeichnis auch verweist. Fehlt das Verzeichnis wird die gleiche Fehlermeldung erzeugt.

Montag Okt 29, 2018

Werkzeuge zur Erhaltung der Softwarearchitektur - CleanUp / ArchUnit - Teil 16

CleanUp / ArchUnit

Nach einer kurzen Pause hier noch zwei weitere Werkzeuge, die einiges leisten.

CleanUp

In Eclipse findet sich unter "Einstellungen / Java / Code Style / Clean up" einiges an Einstellungen, die einem das Leben erleichtern. Mit der CleanUp Funktion können z.B. fehlende "this." ergänzt oder @Overrides automatisch erzeugt werden. Somit hilft diese Funktion insbesondere bei der Übernahme eines Projekts, dass sich nicht an die gewünschten Codestyle Regeln hält.

ArchUnit

ArchUnit stellt ähnlich wie jQAssistant Möglichkeiten zur Verfügung, die Architektur zu analysieren. Hier kommt eine API und nicht wie bei jQAssistant eine Graphdatenbank zum Einsatz. Damit gibt es wahrscheinlich etwas weniger Möglichkeiten der Anlayse, für zentrale Aufgaben ist ArchUnit aber gut geeignet. Näheres zu ArchUnit versuche ich in den nächsten Posts zu schreiben.

Alle Teile der Serie zu Architekturerhaltung in Java

Donnerstag Sep 13, 2018

Spooky Exceptions (11) - ... javax.ejb.EJBException: WFLYEJB0442: Unexpected Error

Umgebung

  • Wildfly 13
  • EE7
  • Eclipselink

Situation

Bei dem Aufruf einer JPA Query wird folgende Exception geworfen
 
   ... javax.ejb.EJBException: WFLYEJB0442: Unexpected Error
   ...
   Caused by: java.lang.StackOverflowError
   at org.eclipse.persistence.jpa.jpql.parser.AbstractExpression.getRoot(AbstractExpression.java:530)
   at org.eclipse.persistence.jpa.jpql.parser.AbstractExpression.getRoot(AbstractExpression.java:530)
   at org.eclipse.persistence.jpa.jpql.parser.AbstractExpression.getRoot(AbstractExpression.java:530)
    ...

Lösung

Ursache dieser Exception ist eine lange Kette von WHERE Bedingungen (ca 2250) in einer JPQL Abfrage, die über Parameter befüllt werden. Es scheint hier Grenzen in der Verarbeitungsfähigkeit zu geben. Solche Anfragen müssen in Einzelanfragen aufgebrochen oder umformuliert werden.

Freitag Jul 13, 2018

Spooky Exceptions (10) - An exception occurred while creating a query in EntityManager

Umgebung

  • Wildfly 13
  • EE7
  • Eclipselink

Situation

Bei dem Aufruf einer JPA Query kommt eine Exception
 
  2018-06-22 12:45:43,615 ERROR [org.jboss.as.ejb3.invocation] (default task-1) WFLYEJB0034: 
  EJB Invocation failed on component DataPrivacyStatementAcceptanceFacade
  for method public abstract de.schoeso.festival.ejb.mde.DataPrivacyStatementAcceptanceList 
  de.schoeso.festival.ejb.mde.facade.DataPrivacyStatementAcceptanceFacadeLocal.findByVariousParameters(): javax.ejb.EJBException: 
  java.lang.IllegalArgumentException: An exception occurred while creating a query in EntityManager:  
  Exception Description: Problem compiling [SELECT x FROM DataPrivacyStatementAcceptance x]. 
  [14, 44] The abstract schema type 'DataPrivacyStatementAcceptance' is unknown.
	at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInNoTx(CMTTxInterceptor.java:223)
	at org.jboss.as.ejb3.tx.CMTTxInterceptor.supports(CMTTxInterceptor.java:418)

Lösung

Ursache dieses Kompilierungsproblems und des fehlenden "abstract schema type" war, dass die Entität nicht in der persistence.xml eingetragen war (bzw. nicht erkannt wurde).

Spooky (missing) Exceptions (9) - Objekt wird vom (Eclipse) JPA Provider nicht in die Datenbank geschrieben

Umgebung

  • Wildfly 10
  • EE7
  • Eclipselink

Situation

Ein Subobjekt einer Entität (OneToOne), das über cascade = CascadeType.ALL angebunden ist, wird bei merge nicht persistiert.

Analyse

In diesem Fall wurde das Objekt nicht im Oberobjekt instanziiert
 
    @OneToOne(cascade = CascadeType.ALL, mappedBy = "repairWarranty", fetch = FetchType.EAGER)
    private StateChange stateChange = null;
  • Bei dem ersten Zugriff auf das Objekt über den getter wurde das Objekt angelegt
  • In einer Livecycle Methode @PostPersist wurde auf das Objekt zum ersten mal zugegriffen
Wenn ein abhägiges Objekt erst in einer Livecycle Methode @PostPersist instanziiert wird, erkennt aktuell (Version 2.6.x) der (Eclipselink) JPA Provider nicht, dass dieses Objekt gespeichert werden muss. Auch wenn ohne ein refresh des Oberobjekts nochmals versucht wird ein merge durchzuführen, werden die Daten nicht in die Datenbank geschrieben (sind aber im Objekt enthalten, was das Debugging deutlich erschwert).

Lösung

Entweder die (indirekte) Instanziierung in den Livecycle Methoden vermeiden oder die Objekte direkt anlegen
 
    @OneToOne(cascade = CascadeType.ALL, mappedBy = "repairWarranty", fetch = FetchType.EAGER)
    private StateChange stateChange = new StateChange ();

Calendar

Feeds

Search

Links

Navigation