ERROR [proxy.pojo.BasicLazyInitializer] Javassist Enhancement failed:
org.alfresco.repo.avm.PlainDirectoryNodeImpl
java.lang.RuntimeException: by java.lang.IllegalAccessError:
class org.hibernate.proxy.HibernateProxy_$$_javassist_110 cannot access its
superinterface org.alfresco.repo.avm.PlainDirectoryNode
at javassist.util.proxy.ProxyFactory.createClass3(ProxyFactory.java:342)In der Datei server/default/deploy/ejb3.deployer/META-INF/persistence.properties ist der Hibernate Bytecode Provider von “javassist” auf cglib zu ändern:

#hibernate.bytecode.provider=javassist
hibernate.bytecode.provider=cglibWarum das so ist weiÃ? der Geier. Und der hier, der weiÃ? das offensichtlich auch. Danke!

Bookmark It

Hide Sites

Wer’s genau wissen will: http://jira.jboss.com/jira/browse/JBPORTAL

Bookmark It

Hide Sites

java.lang.UnsatisfiedLinkError: no Win32NetBIOS in java.library.path
at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1682)
at java.lang.Runtime.loadLibrary0(Runtime.java:823)
at java.lang.System.loadLibrary(System.java:1030)
at [...]

Die Lösung: Das Bundle installieren und aus dem bin-Verzeichnis die Datei Win32NetBIOS.dll holen. Diese ins Verzeichnis ${jboss.home}/bin kopieren.

Bookmark It

Hide Sites

More than one root node in index: 2…deployment failed.

Die Ursache war einfach: wenn Die Alfresco-Datenbank gelöscht wird, MUSS auch das Verzeichnis alf_data geleert werden.

Bookmark It

Hide Sites

Data truncation: Data too long for column 'MODIFIABLE' at row 1

Wobei das Feld MODIFIABLE vom Typ bit ist und hier der Wert ‘1‘ eingefügt werden soll.

Die Lösung ist simpel: Es handelt sich um einen Bug im MySQL JDBC-Treiber Version 5.0.3. Also: Upgrade auf z.B. 5.0.4 und gut is.

Bookmark It

Hide Sites

So, jetzt kommt die Herausforderung: Integration von Alfresco 2.0 in JBoss AS 4.0.5 unter Portal 2.4.1 und MySQL. Zunächst also mal in den Alfresco-Foren gestöbert. Die schlechte Nachricht: Es geht nicht. Die gute Nachricht: Es geht doch, wenn man sich etwas Mühe gibt. Die Kernaussage dieses Wiki-Eintrages ist, dass im aktuellen Release einige Issues existieren, die den Betrieb von Alfresco 2.0 unter JBoss Portal 2.4.1 unmöglich machen. Diese Issues sin in aktuellen Revisionen des SVN-Repositories jedoch bereits gefixt, so dass ein manuelles Build eines SVN-Snapshots nötig ist. Es gibt glücklicherweise eine Wiki-Eintrag, der beschreibt, wie das zu bewerkstelligen ist. Na dann wollen wir mal sehen, ich werd das jetzt mal ganz brav step-bystep befolgen…

1. SVN-Client Installieren (Subclipse beispielsweise)
2. Das Alfresco-Repository unter svn://svn.alfresco.com/alfresco/HEAD konnektieren und Revision 574 holen (dauert erwartungsgemäÃ? ewig…)
3. Die Umgebungsvariable JBOSS_HOME auf die JBoss AS Installation setzen
4. Ant herunterladen und als Standalone installieren. Das ANT-bin-Verzeichnis in die Umgebungsvariable PATH aufnehmen. Umgebungsvariable ANT_HOME setzen.
5. JAVA_HOME aufs JDK setzen
6. In dem Verzeichnis root/common des Alfresco-Projektes das Tartget build-jboss ausführen: ant build-jboss. Es entstehen folgende Dateien, die vom build-Script freundlicherweise gleich deployed werden:
7. • ${jboss.home}/bin/.hotspot_compiler (was auch immer der macht…)
   • ${jboss.home}/server/default/lib/mysql-connector-java-5.0.3-bin.jar (andere MySQL-Treiber werden entfernt)
   • ${jboss.home}/server/default/deploy/alfresco.war
8. In der Datei ${jboss.home}/bin/run.bat (bzw. run.sh) folgenden Code zu den JAVA_OPTS hinzufügen:
   -server -XX:MaxPermSize=128m cvx (Siehe auch: Das PermgenSpace-Problem)
9. Leere Datenbank “alfresco” in MySQL anlegen:
   create database alfresco;
grant all privileges on alfresco.* to 'alfresco'@'localhost'
identified by 'alfresco' with grant option;
grant all privileges on alfresco.* to 'alfresco'@'localhost.localdomain'
identified by 'alfresco' with grant option;
10. Und go!

So, jetzt kommt also der Moment, in dem die Kuh den Schwanz hebt… uuund … läuft! Fast.

Ein Problem gibt es jetzt noch: Nach dem erfolgreichen Einklinken des AlfrescoClientWindow-Portlets bzw. beim Anzeigen desselben erscheint die Fehlermeldung:

Unable to find setter method for attribute acceptCharset in /jsp/browse/browse.jsp.

Ein Blick in diese Dateio zeigt:

<h:form acceptCharset="UTF-8" id="browse">

Der h-Namespace kommt von MyFaces. Achja, da war ja noch was, die MyFaces-Bibliotheken sollten ohnehin ersetzt werden. Also:

${jboss.home}/server/default/deploy/jbossweb-tomcat55.sar/jsf-libs/myfaces-* löschen und durch aktuelle (1.1.5+) ersetzen. Und? Nee!

Nun kommt im AlfrecoClientWindow:

javax.faces.FacesException: org.apache.jasper.JasperException:
The absolute uri: http://java.sun.com/jsf/html
cannot be resolved in either web.xml or the jar files
deployed with this application

Na toll, was soll das jetzt? Nach einiger Recherche habe ich nun die myfaces-libs in der Version 1.1.1 nach ${jboss.home}/server/default/deploy/jbossweb-tomcat55.sar/jsf-libs kopiert. Nun ist alles super!

13:29:40,531 INFO [org.jboss.system.server.Server] JBoss (MX MicroKernel)
[4.0.5.GA (build: CVSTag=Branch_4_0 date=200610162339)]
Started in 4m:11s:235ms (hmpf...)

Bookmark It

Hide Sites

Da wir gerade dabei sind, Alfresco (ursprünglich in der Version 1.4) bei einem unserer Kunden einzuführen, stellt sich nun
natürlich die spannende Frage, was uns dieses Major Release nun konkret bringt.

Zunächst wäre da mal die lange erwartete WCMS-Komponente, also ein JSR-170 konformes System für Webcontent.

Hier zunächst mal ein Ausschnitt aus dem Original Post:

[...] This release introduces a number of new features, including:

• GPL with FLOSS exception
• Web Content Managment 1.0 with:
  • Web Project Wizard
  • Forms Management Wizard
  • Website Development and Staging
  • XML Content Authoring
  • FreeMarker, XSL and XSL-FO transformations
  • Virtualization and In-Context Preview
  • Workflow for change sets
• Federated Search
• OpenSearch support
• Add-on Module Management
• Tree Navigation (AJAX)
• Multilingual Services

[...]

Nun gut, sagt mir erstmal noch so viel, muss ich gestehen. Werde mich mal dranmachen, das ganze zu evaluieren…

Bookmark It

Hide Sites

Folgende Schritte waren letztendlich nötig:

1. Server Konfiguration

In der Datei ${jboss.home}/server/default/conf/service.xml muss folgender Block eingefügt (bzw. einkommentiert und angepasst) werden:

<mbean code="org.jboss.services.binding.ServiceBindingManager"
name="jboss.system:service=ServiceBindingManager">
<attribute name="ServerName">ports-01</attribute>
<attribute name="StoreURL">
${jboss.home.url}/server/default/conf/service-bindings.xml
</attribute>
<attribute name="StoreFactoryClassName">
org.jboss.services.binding.XMLServicesStoreFactory
</attribute>
</mbean>Damit wird über service-bindings.xml ein alternatives Binding, also eine alternative Portkonfiguration definiert. Diese Date findet man als Vorlage unter ${jboss.home}/docs/examples/binding-manager/sample-bindings.xml

Inder Datei service-bindings.xml werden zwei Serverkonfigurationen definiert: ports-default, die bleibt so wie sie ist, und server-01, das ist unsere modifizierte Konfiguration.

Hier die wichtigen Stellen aus dieser Datei:

<service-bindings>
<!-- Standardkonfiguration -->
<server name="ports-default">
<service-config name="jboss:service=Naming"
delegateClass="org.jboss.services.binding.AttributeMappingDelegate">
<delegate-config portName="Port" hostName="BindAddress">
<attribute name="RmiPort">1098</attribute>
</delegate-config>
<binding port="1099" host="${jboss.bind.address}" />
</service-config>
<service-config name="jboss:service=WebService"
delegateClass="org.jboss.services.binding.AttributeMappingDelegate">
<delegate-config portName="Port" />
<binding port="8083" />
</service-config>
<!-- usw. für alle definierten Portnummern -->
</server>
<!-- Hier wirds spannend... -->
<server name="ports-01">
<!-- Umkonfiguration des Naming-Dienstes -->
<service-config name="jboss:service=Naming"
delegateClass="org.jboss.services.binding.AttributeMappingDelegate">
<delegate-config portName="Port" hostName="BindAddress">
<attribute name="RmiPort">1198</attribute>
</delegate-config>
<binding port="1199" host="${jboss.bind.address}" />
</service-config>
<!-- Der Rest bleibt wie er ist... -->
</server>
</service-bindings>

2. Patch für JBoss ESB 4.0

Beim Hochfahren der jUDDI-Registry ver sucht der ESB, diese bei localhost:1099 anzumelden, was ja normalerweise auch richtig ist. Nutzt man den ESB mit jUDDI, so muss im Verzeichnis ${jboss.home}/server/default/conf die Datei juddi.properties vorhanden sein. In dieser lässt sich so einiges bzgl. der Registry für den Service-Bus konfigurieren, unter Anderem folgendes:

# JNDI settings (used by RMITransport
java.naming.factory.initial=org.jnp.interfaces.NamingContextFactory
java.naming.provider.url=jnp://localhost:1199
java.naming.factory.url.pkgs=org.jboss.namingSuper, genau, was man braucht! Denkste. Die olle Registry meldet sich immer noch auf localhost:1099 an. Der Grung dafür ist ein Bug im JBoss ESB, genauer am jUDDI-Proxy. Folgende Klasse existiert im ESB:

# JNDI settings (used by RMITransport)
package org.jboss.internal.soa.esb.dependencies;
import java.io.File;
import java.net.URI;
import java.util.Properties;
import java.io.IOException;
import java.io.InputStream;
import javax.naming.InitialContext;
public class JuddiRMIService extends ServiceMBeanSupport
implements JuddiRMIServiceMBean {
private Logger logger = Logger.getLogger(this.getClass());
protected void startService() throws Exception {
logger.info("starting juddi RMI service");
final String confURL = System.getProperty("jboss.server.config.url") ;
final URI confDirURI = new URI(confURL) ;
final File confDir = new File(confDirURI) ;
System.setProperty("juddi.propertiesFile", confDir + "/juddi.properties");
JNDIRegistration.register();
}
protected void stopService() throws Exception {
logger.info("Unbinding juddi services");
final InitialContext ic = new InitialContext() ;
ic.unbind(JNDIRegistration.INQUIRY_SERVICE) ;
ic.unbind(JNDIRegistration.PUBLISH_SERVICE) ;
}
}Der Fehler tritt bei JNDIRegistration.register() auf. Das Problem ist, dass die jUDDI-Konfiguratiuon beim Aufruf dieser Static-Methode noch gar nicht eingelesen ist, also wird fröhlich weiter beim Standard JNDI-Port localhost:1099 angemeldet. Hier der Patch:

package org.jboss.internal.soa.esb.dependencies;
import java.io.File;
import java.net.URI;
import java.util.Properties;
import java.io.IOException;
import java.io.InputStream;
import javax.naming.InitialContext;
import org.apache.juddi.registry.RegistryEngine;
import org.apache.juddi.registry.rmi.JNDIRegistration;
import org.apache.log4j.Logger;
import org.jboss.system.ServiceMBeanSupport;
import org.apache.juddi.util.Config;
import org.apache.juddi.util.Loader;
public class JuddiRMIService extends ServiceMBeanSupport
implements JuddiRMIServiceMBean {
private Logger logger = Logger.getLogger(this.getClass());
private static final String PROPFILE_NAME = "juddi.properties";
protected void startService() throws Exception {
logger.info("starting juddi RMI service");
final String confURL = System.getProperty("jboss.server.config.url") ;
final URI confDirURI = new URI(confURL) ;
final File confDir = new File(confDirURI) ;
System.setProperty("juddi.propertiesFile", confDir + "/juddi.properties");
logger.info("** Patch om@form4: start preloading properties");
try {
InputStream stream = Loader.getResourceAsStream(PROPFILE_NAME);
if (stream != null) {
Properties props = new Properties();
props.load(stream);
Config.addProperties(props);
logger.info("** Patch om@form4: preloading properties successful");
}
} catch (IOException ioex) {
logger.error("An error occured while loading properties
from: "+PROPFILE_NAME,ioex);
}
JNDIRegistration.register();
}
protected void stopService() throws Exception {
logger.info("Unbinding juddi services");
final InitialContext ic = new InitialContext() ;
ic.unbind(JNDIRegistration.INQUIRY_SERVICE) ;
ic.unbind(JNDIRegistration.PUBLISH_SERVICE) ;
}
}Jetzt muss noch das Build der JBoss ESB-Quellen angeschmissen werden und es entsteht u. A. die Datei jbossesb-dependencies.jar, die in der Original-Distribution ersetzt werden muss.

Nun geht auch das.

3. Umkonfiguration des ESB

Was auch stundenlanges Debuggen erfordert hat, ist eigentlich ganz einfach: In der Datei ${jboss.home}/server/default/conf/jbossesb.xml wird die jndi-url lapidar mit “localhost” angegeben. Das muss konkretisiert werden. Aus:

<jms-provider name="JBossMQ"
connection-factory="ConnectionFactory"
jndi-context-factory="org.jnp.interfaces.NamingContextFactory"
jndi-URL="localhost">wird:

<jms-provider name="JBossMQ"
connection-factory="ConnectionFactory"
jndi-context-factory="org.jnp.interfaces.NamingContextFactory"
jndi-URL="localhost:1199">Ã?hnliches nochmal in ${jboss.home}/server/default/conf/jbossesb-properties.xml . Aus:

<property name="org.jboss.soa.esb.jndi.server.url" value="localhost"/>wird:

<property name="org.jboss.soa.esb.jndi.server.url" value="localhost:1199"/>

4. jndi.properties umkonfigurieren

Zu guter letzt noch in der Datei ${jboss.home}/server/default/conf/jndi.properties folgende Zeile ergänzen:

java.naming.provider.url=jnp://localhost:1199Jetzt ist alles gut!

Bookmark It

Hide Sites

folgende:
set JAVA_OPTS=%JAVA_OPTS% -Xms128m -Xmx512m
-XX:+CMSPermGenSweepingEnabled -XX:MaxPermSize=128m
-Dsun.rmi.dgc.client.gcInterval=3600000
-Dsun.rmi.dgc.server.gcInterval=3600000

Der PermGenSpace liegt standardmä�ig bei 64m, was für den feisten JBoss AS offensichtlich etwas knapp bemessen ist. Hierüber wird dieser Wert auf 128m erhöht.
Trotzdem geht der JBoss mit dem PermGenSpace offensichtlich etwas schluderig um, denn auch bei 128m ist dieser nach einem Tag Intensiver Entwicklung voll, und der Server muss neu gestartet werden. Deutet auf ein Speicherleck hin…

Bookmark It

Hide Sites

Kurz zur Erklärung: Smooks ist ein Framework zur generischen Verarbeitung von XML-Dateien, bzw. XML-Fragmenten. Die Verarbeitung ist einfach: In einer Mapping-datei wird für jeden XML-Pfad ein Handler definiert, der über das Visitor-Pattern irgendetwas ausführt. So kann für ein Element (oder einen Teilbaum) z.B. ein XSLT ausgeführt werden oder auch völlig individueller Java-Codeausgeführt werden.

Hier ein Beispiel aus der Mapping-Datei (smooks-res.xml):

<smooks-resource selector="ORDER"
useragent="from-type:text/xml:fullfillorder and
from:dvdstore:orderdispatchservice"
path="org.milyn.javabean.ProcessingPhaseBeanPopulator" >
<param name="beanId">ORDER</param>
<param name="beanClass">org.jboss.soa.esb.dvdstore.Order</param>
<param name="addToList">true</param>
</smooks-resource>
<smooks-resource selector="ORDER"
useragent="from-type:text/xml:fullfillorder and
from:dvdstore:orderdispatchservice"
path="org.milyn.javabean.ProcessingPhaseBeanPopulator" >
<param name="beanId">order</param>
<param name="attributeName">orderId</param>
</smooks-resource>
<!-- ... repeat for each attribute ... -->

In diesem Beispiel wird für jedes Element “ORDER” der ProcessingPhaseBeanPopulator “besucht”. Der ProcessingPhaseBeanPopulator wird vom smooks-Framework über eine sog. Cartridge mitgeliefert. Er hat die Aufgabe, aus dem element “ORDER” ein POJO, also eine Java-Klasse zu generieren. Attribute können zu Java-Properties gemappt werden und für Unterelemente können ebenfalls Visitors definiert werden, die beispielsweise wiederum Properties setzen. Sowie sogut. Das Problem ist bloss, dass bei “echten” Business-Daten die Datenstrukturen nicht so trivial sind, wie in dem vom ESB mitgelieferten Sample “quickstarts/transformXML2POJO“. Habe ich ein ORDER-Element mit 30 oder mehr Unterelementen, die die Properties der ORDER definieren, wird mein smooks-mappingfile recht umfangreich und vor allem sehr wartungsfeindlich.

Schön wäre eine Smooks-Cartridge, die die Unterlemente eines XML-Elements automatisch auf die Properties (genaugesagt auf die Setter) meines POJO Mappt. So kann mit minimaler Konfiguration eine ganze Reihe von umfangreichen XML-Strukturen auf POJOs transformiert werden, ohne tonnenweise quasi-redundanten Konfigurationscode zu erzeugen.

Hierzu habe ich die von smooks mitgelieferte javabeans-cartridge etwas modifiziert, so dass folgende Konfiguration möglich ist:

<smooks-resource selector="ORDER"
useragent="from-type:text/xml:fullfillorder and
from:dvdstore:orderdispatchservice"
path="org.milyn.javabean.MyProcessingPhaseBeanPopulator" >
<param name="beanId">order</param>
<param name="beanClass">org.jboss.soa.esb.dvdstore.Order</param>
<param name="attributesFromChildren">true</param>
</smooks-resource>

Damit das funktioniert, habe ich in der Klasse ProcessingPhaseBeanPopulator etwas Code ergänzt.

Zunächst das Einlesen der Konfiguration, die nun den Parameter “attributesFromChildren” unterstützen soll:

public void setConfiguration(SmooksResourceConfiguration config) {
// ... existing code
// START Added by om, form4
attributesFromChildren =
config.getBoolParameter("attributesFromChildren", false);
// END Added by om, form4
}

Und das Processing im eigentlichen Visitor:

public void visit(Element element, ContainerRequest request) {
Object bean = getBean(request);
// START Added by om, form4
if (attributesFromChildren) {
NodeList children = element.getElementsByTagName("*");
for (int i = 0; i < bean.getClass().getMethods().length; i++) {
Method method = bean.getClass().getMethods()[i];
if (method.getName().startsWith("set")) {
String attr = method.getName().replaceAll("^set", "").toLowerCase();
for (int j = 0; j < children.getLength(); j++) {
Element child = (Element) children.item(j);
if (attr.equalsIgnoreCase(child.getNodeName())) {
try {
String val = DomUtils.getAllText(child, false);
method.invoke(bean, new Object[] { val });
} catch (Exception e) {
logger.error(e); // etwas ignorant...
}
break;
}
}
}
}
}
// END Added by om, form4
// ... go on with original code ...
}


Bookmark It

Hide Sites

<action class="org.jboss.soa.esb.actions.SeamProxy" name="MySeamComponent"/>

Der Name MySeamComponent würde innerhalb einer solchen Out-of-the-Box-Action automatisch auf das @Name der Seam-Komponente gemappt werden (die Action löst das intern über einen JNDI-Lookup).

Weiterhin im Gespräch ist ein Action-Interface MarshalledActionProcessor mit einer einzigen Methode mit folgender Signatur:

public Object process(Object[] objects) throws ActionProcessingException;

So kann innerhalb von Seam, wie in Seam üblich, mit einem ganz normalen Objekt gearbeitert werden, während sich das ESB-Developer-Team von JBoss überlegt wie sie eine ESB-Message in ein Objekt transformiert (marshalled).

Dies sind jedoch lediglich erste Gedanken der ESB-Entwickler. Die Diskussion hierüber kann derzeit im JBoss ESB Developer Forum nachvollzogen werden.

Bookmark It

Hide Sites

10:32:40,531 WARN [ServiceController] Problem starting service
jboss.mq:service=PersistenceManager
org.jboss.mq.SpyJMSException: Could not resolve uncommited transactions.
Message recovery may not be accurate; - nested throwable:
(com.mysql.jdbc.exceptions.MySQLSyntaxErrorException: Every derived table
must have its own alias)
at org.jboss.mq.pm.jdbc2....resolveAllUncommitedTXs(PersistenceManager.java:492)
...
at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
... at blablabla ...
at org.jboss.Main$1.run(Main.java:490)
at java.lang.Thread.run(Thread.java:595)
Caused by: com.mysql.jdbc.exceptions.MySQLSyntaxErrorException:
Every derived table must have its own alias
at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:936)
at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:2870)
... at blubber, sülz ...
at org.jboss.resource.adapter.jdbc.WrappedPreparedStatement.
executeQuery(WrappedPreparedStatement.java:236)
at org.jboss.mq.pm.jdbc2.PersistenceManager.
resolveAllUncommitedTXs(PersistenceManager.java:424)
... 111 more

Nach einigen Nachforschungen hat sich herausgestellt, dass das folgende SQL-Statement von der MySQL-Datenbank hochnäsig zurückgewiesen wurde:

SELECT_MAX_TX = SELECT MAX(TXID) TXID FROM
(SELECT MAX(TXID) AS TXID FROM JMS_TRANSACTIONS
UNION SELECT MAX(TXID) AS TXID FROM JMS_MESSAGES)

Warum? Weil das Subselect offensichtlich auch einen Alias benötigt. Na von mir aus. Ein Schmökern in den JBoss-Foren und im JIRA hat mir auch nicht wirklich weitergeholfen. Beim Vergleich diverser User-Erfahrungen stellte sich herau, dass das Problem nicht auftritt, wenn man MySQL in einer Version gröÃ?er als 4.0.13 und kleiner als 4.0.20 verwendet. Naja. Mit meiner brandheiÃ?en 5.0.27 bin ich da ja weit von entfernt. Im Bugtracker diskutieren die Entwickler lediglich die Frage, ob der Bug gefixt wird, dass er ja eigentlich schon gefixt ist, warum er dann nicht im Release ist, das das wohl vergessen wurde, ob er denn überhaupt gefixt werden muss, usw. usw…

Nun, die Lösung ist einfach:

Man schnappe sich die die Datei
[jboss.root]/server/default/deploy/jms/hsqldb-jdbc2-service.xml

und ändere diese Zeile:
SELECT_MAX_TX = SELECT MAX(TXID) TXID FROM
(SELECT MAX(TXID) AS TXID FROM JMS_TRANSACTIONS
UNION SELECT MAX(TXID) AS TXID FROM JMS_MESSAGES)
wie folgt ab:
SELECT_MAX_TX = SELECT MAX(TXID) TXID FROM
(SELECT MAX(TXID) AS TXID FROM JMS_TRANSACTIONS UNION
SELECT MAX(TXID) AS TXID FROM JMS_MESSAGES) AS ichbindergottverdammtealias

Nun erzählt mir mein lieber JBoss Server noch dass die Tabelle JMS_TRANSACTIONS nicht existiert. Also in der selben Datei nochmal kurz gepatcht. Folgende Zeilen:

CREATE_MESSAGE_TABLE =
CREATE CACHED TABLE JMS_MESSAGES ( MESSAGEID INTEGER NOT NULL,
DESTINATION VARCHAR(255) NOT NULL, TXID INTEGER, TXOP CHAR(1),
MESSAGEBLOB OBJECT, PRIMARY KEY (MESSAGEID, DESTINATION) )
CREATE_TX_TABLE = CREATE CACHED
TABLE JMS_TRANSACTIONS ( TXID INTEGER, PRIMARY KEY (TXID) )

ändern zu:
CREATE_MESSAGE_TABLE =
CREATE TABLE JMS_MESSAGES ( MESSAGEID INTEGER NOT NULL,
DESTINATION VARCHAR(255) NOT NULL, TXID INTEGER, TXOP CHAR(1),
MESSAGEBLOB BLOB, PRIMARY KEY (MESSAGEID, DESTINATION) )
CREATE_TX_TABLE = CREATE TABLE JMS_TRANSACTIONS ( TXID INTEGER, PRIMARY KEY (TXID) )


Nun ist Ruhe.

Bookmark It

Hide Sites