camunda cdi and multiple datasources

Ich durfte mich die letzten Tage mit einem ziemlich fiesen Fehler rum ärgern.

Wir optimieren unsere Bestellungen und vor allem automatisieren wir unseren gesamten Verarbeitungsprozess mit dem Backend.

Der gesamte Bestand und Bestellverfahren wird automatisch mit dem Shop, dem Backend und dem Versender abgeglichen.

Der Prozess zur Bestellübergabe wurde in camunda definiert. Die Service Tasks greifen auf CDI Beans zu. Diese Beans greifen auf JPA Ressourcen zurück.

Es wurden Projektbedingt 2 Resourceprojekte mit verschiedenen JTA- Resources definiert, die aber aufgrund der Architektur auf die gleiche Datenbank zugreifen.

 

Durch die schnelle Verarbeitung des Prozesses kommt  der Application Server durcheinander und Crasht bei der Verarbeitung der Transaktionen.  Einer der Ressourcenmanager lockt die Tabelle und verhindert das weitere verarbeiten der Daten.

Leider ist es mir nicht gelungen eine andere Lösung zu finden als beiden JPA Projekten der gleichen JNDI- Resource zu geben.  🙁

Jemand noch eine andere Idee?

PrimeFaces GZip Error

Ein häufig auftretender und nicht erklärbarer Fehler in Primefaces ist der GZIP Error. Es gibt unterschiedliche Möglichkeiten bei Aktionen die definiert werden und eventuell falsch ausgeführt werden.

Wir suchen seit nunmehr – sporatisch – 1 Monat nach den Fehler und immer ist es lediglich ein kleines Quäntchen Glück das uns gefehlt hat. Es dreht sich um den wunderbaren Parameter ajax den man in den meisten Komponenten von Primefaces angeben kann und dieser dann entscheidet ob ein ajax Befehl ausgeführt wird oder nicht.

Jetzt kommt das große Ding und zugleich die Erklärung. Wenn man über outcomes gesteuerte Navigation- Elements anlegt in seiner faces-config.xml werden anhand eines String die Elmente gerootet. z.B.

<p:commandButton value="Step1" action="to-step-1" />

In der faces-config.xml werde ihr so etwas ähnliches vorfinden:

<navigation-rule>
		<display-name>Step 0</display-name>
		<from-view-id>/step0.xhtml</from-view-id>
		<navigation-case>
		 	<from-outcome>to-step-1</from-outcome>
			<to-view-id>/step1.xhtml</to-view-id>
		</navigation-case>
</navigation-rule>

Wenn ihr dieses Beispiel jetzt ausführen würdet, lauft ihr in eine Falle die nicht schön ist und aus der mann nur ganz schwer wieder heraus kommt weil es keine konkreten Hinweise dazu gibt. Wenn man in die Browserconsole oder die Entwicklertools von z.B. google Chrome schaut werdet ihr sehen das nach dem laden von step1.xhtml euer jQuery abstürzt und somit die Seite jegliche Funktionalität verliert die euch Primefaces bietet.

Einfacher Lösungsansatz:

<p:commandButton value="Step1" action="to-step-1" ajax="false" />

Der kleine Parameter ajax=“false“ verwandelt den Javascript Aufruf für den Button in einen Standardaufruf um und „refreshed“ die Seite somit korrekt und alle Funktionen werden korrekt ausgeführt!

Und wieder von Anfang an

In dieser Woche habe ich ein Systemupdate gefahren. Leider ging dabei einiges schief wie ihr seht. Ich weiß nicht warum es nur den Blog betroffen hat aber leider wurden alle meine Blogdaten gelöscht. Es existiert zwar ein Backup aber leider sind die Daten schon so alt vom dem Blog das es sich nicht lohnen würde.

Etwas gutes hat es dennoch. Ich kann einen sauberen Blog anbieten und euch mit neueren Informationen rund um:

  • JSF2
  • Primefaces3
  • EJB3
  • JEE6
  • Liferay
  • Android

Dieses mal werde ich mich darauf konzentrieren beim technischen Bereich zu bleiben und nicht wieder in alle anderen Sparten abzuweichen. Ich wünsche euch viel Spaß bei meinen neuen Einträgen.