[Design of JBoss Portal] - Portal 2.7 with Postgres
by dloebbe
Hi,
I can't get running the portal in version 2.7 (BETA1 or CR1 makes no difference) with a postgres database version 8.3.
During the initial setup after creating all necessary tables and while inserting the default content for the cms the following error occurs:
| 15:18:18,457 INFO [JBossCachePersistenceManager] -------------------------------------------------
| 15:18:18,457 INFO [JBossCachePersistenceManager] JBossCachePersistenceManager is fully loaded.....
| 15:18:18,457 INFO [JBossCachePersistenceManager] -------------------------------------------------
| 15:18:18,692 WARN [JDBCExceptionReporter] SQL Error: 0, SQLState: null
| 15:18:18,692 ERROR [JDBCExceptionReporter] Batch-Eintrag 0 insert into jbp_cms_version_node (NODE_ID, NODE_DATA, PK) values (deadbeef-face-babe-cafe-babecafebabe, <stream of 109 bytes>, 30) wurde abgebrochen. Rufen Sie 'getNextException' auf, um die Ursache zu erfahren.
| 15:18:18,692 WARN [JDBCExceptionReporter] SQL Error: 0, SQLState: 42804
| 15:18:18,692 ERROR [JDBCExceptionReporter] ERROR: column "node_data" is of type oid but expression is of type bytea
| 15:18:18,692 ERROR [AbstractFlushingEventListener] Could not synchronize database state with session
| org.hibernate.exception.SQLGrammarException: Could not execute JDBC batch update
| at org.hibernate.exception.SQLStateConverter.convert(SQLStateConverter.java:67)
| at org.hibernate.exception.JDBCExceptionHelper.convert(JDBCExceptionHelper.java:43)
| at org.hibernate.jdbc.AbstractBatcher.executeBatch(AbstractBatcher.java:253)
| at org.hibernate.jdbc.AbstractBatcher.prepareStatement(AbstractBatcher.java:92)
| at org.hibernate.jdbc.AbstractBatcher.prepareStatement(AbstractBatcher.java:87)
| at org.hibernate.jdbc.AbstractBatcher.prepareBatchStatement(AbstractBatcher.java:222)
| at org.hibernate.persister.entity.AbstractEntityPersister.insert(AbstractEntityPersister.java:2224)
| at org.hibernate.persister.entity.AbstractEntityPersister.insert(AbstractEntityPersister.java:2660)
| at org.hibernate.action.EntityInsertAction.execute(EntityInsertAction.java:56)
| at org.hibernate.engine.ActionQueue.execute(ActionQueue.java:250)
| at org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:234)
| at org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:141)
| at org.hibernate.event.def.AbstractFlushingEventListener.performExecutions(AbstractFlushingEventListener.java:298)
| at org.hibernate.event.def.DefaultFlushEventListener.onFlush(DefaultFlushEventListener.java:27)
| at org.hibernate.impl.SessionImpl.flush(SessionImpl.java:1000)
| at org.hibernate.impl.SessionImpl.managedFlush(SessionImpl.java:338)
| at org.hibernate.transaction.CacheSynchronization.beforeCompletion(CacheSynchronization.java:59)
| at com.arjuna.ats.internal.jta.resources.arjunacore.SynchronizationImple.beforeCompletion(SynchronizationImple.java:114)
| at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.beforeCompletion(TwoPhaseCoordinator.java:247)
| at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.end(TwoPhaseCoordinator.java:86)
| at com.arjuna.ats.arjuna.AtomicAction.commit(AtomicAction.java:177)
| at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.commitAndDisassociate(TransactionImple.java:1389)
| at com.arjuna.ats.internal.jta.transaction.arjunacore.BaseTransaction.commit(BaseTransaction.java:135)
| at com.arjuna.ats.jbossatx.BaseTransactionManagerDelegate.commit(BaseTransactionManagerDelegate.java:87)
| at org.jboss.tm.usertx.client.ServerVMClientUserTransaction.commit(ServerVMClientUserTransaction.java:140)
| at org.hibernate.transaction.JTATransaction.commit(JTATransaction.java:146)
| at org.jboss.portal.cms.hibernate.state.JBossCachePersistenceManager.store(JBossCachePersistenceManager.java:1315)
| at org.apache.jackrabbit.core.version.VersionManagerImpl.<init>(VersionManagerImpl.java:157)
| at org.apache.jackrabbit.core.RepositoryImpl.createVersionManager(RepositoryImpl.java:400)
| at org.apache.jackrabbit.core.RepositoryImpl.<init>(RepositoryImpl.java:294)
| at org.apache.jackrabbit.core.RepositoryImpl.create(RepositoryImpl.java:557)
| at org.jboss.portal.cms.impl.jcr.jackrabbit.JackrabbitJCRService.start(JackrabbitJCRService.java:107)
| at org.jboss.portal.cms.impl.jcr.JCRCMS.startJCR(JCRCMS.java:326)
| at org.jboss.portal.cms.impl.jcr.JCRCMS.startService(JCRCMS.java:291)
| at org.jboss.system.ServiceMBeanSupport.jbossInternalStart(ServiceMBeanSupport.java:289)
| at org.jboss.system.ServiceMBeanSupport.start(ServiceMBeanSupport.java:196)
| at org.jboss.portal.jems.as.system.AbstractJBossService.start(AbstractJBossService.java:73)
| at sun.reflect.GeneratedMethodAccessor25.invoke(Unknown Source)
| at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
| at java.lang.reflect.Method.invoke(Method.java:585)
| at org.jboss.portal.jems.as.system.JBossServiceModelMBean$ServiceMixin.execute(JBossServiceModelMBean.java:486)
| at org.jboss.portal.jems.as.system.JBossServiceModelMBean$ServiceMixin.startService(JBossServiceModelMBean.java:452)
| at org.jboss.system.ServiceMBeanSupport.jbossInternalStart(ServiceMBeanSupport.java:289)
| at org.jboss.system.ServiceMBeanSupport.start(ServiceMBeanSupport.java:196)
| at org.jboss.portal.jems.as.system.JBossServiceModelMBean$6.invoke(JBossServiceModelMBean.java:374)
| at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
| at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
| at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
| at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
| at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
| at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
| at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
| at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.java:995)
| at $Proxy0.start(Unknown Source)
| at org.jboss.system.ServiceController.start(ServiceController.java:417)
| at org.jboss.system.ServiceController.start(ServiceController.java:435)
| at org.jboss.system.ServiceController.start(ServiceController.java:435)
| at org.jboss.system.ServiceController.start(ServiceController.java:435)
| at org.jboss.system.ServiceController.start(ServiceController.java:435)
| at org.jboss.system.ServiceController.start(ServiceController.java:435)
| at org.jboss.system.ServiceController.start(ServiceController.java:435)
| at org.jboss.system.ServiceController.start(ServiceController.java:435)
| at org.jboss.system.ServiceController.start(ServiceController.java:435)
| at org.jboss.system.ServiceController.start(ServiceController.java:435)
| at org.jboss.system.ServiceController.start(ServiceController.java:435)
| at sun.reflect.GeneratedMethodAccessor9.invoke(Unknown Source)
| at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
| at java.lang.reflect.Method.invoke(Method.java:585)
| at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
| at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
| at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
| at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
| at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
| at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
| at $Proxy4.start(Unknown Source)
| at org.jboss.deployment.SARDeployer.start(SARDeployer.java:304)
| at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
| at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
| at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
| at java.lang.reflect.Method.invoke(Method.java:585)
| at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
| at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
| at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
| at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
| at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
| at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
| at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
| at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
| at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
| at $Proxy198.start(Unknown Source)
| at org.jboss.deployment.XSLSubDeployer.start(XSLSubDeployer.java:197)
| at org.jboss.deployment.MainDeployer.start(MainDeployer.java:1025)
| at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:819)
| at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:782)
| at sun.reflect.GeneratedMethodAccessor30.invoke(Unknown Source)
| at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
| at java.lang.reflect.Method.invoke(Method.java:585)
| at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
| at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
| at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
| at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
| at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
| at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
| at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
| at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
| at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
| at $Proxy9.deploy(Unknown Source)
| at org.jboss.deployment.scanner.URLDeploymentScanner.deploy(URLDeploymentScanner.java:421)
| at org.jboss.deployment.scanner.URLDeploymentScanner.scan(URLDeploymentScanner.java:634)
| at org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.doScan(AbstractDeploymentScanner.java:263)
| at org.jboss.deployment.scanner.AbstractDeploymentScanner.startService(AbstractDeploymentScanner.java:336)
| at org.jboss.system.ServiceMBeanSupport.jbossInternalStart(ServiceMBeanSupport.java:289)
| at org.jboss.system.ServiceMBeanSupport.jbossInternalLifecycle(ServiceMBeanSupport.java:245)
| at sun.reflect.GeneratedMethodAccessor3.invoke(Unknown Source)
| at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
| at java.lang.reflect.Method.invoke(Method.java:585)
| at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
| at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
| at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
| at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
| at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
| at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.java:978)
| at $Proxy0.start(Unknown Source)
| at org.jboss.system.ServiceController.start(ServiceController.java:417)
| at sun.reflect.GeneratedMethodAccessor9.invoke(Unknown Source)
| at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
| at java.lang.reflect.Method.invoke(Method.java:585)
| at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
| at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
| at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
| at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
| at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
| at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
| at $Proxy4.start(Unknown Source)
| at org.jboss.deployment.SARDeployer.start(SARDeployer.java:304)
| at org.jboss.deployment.MainDeployer.start(MainDeployer.java:1025)
| at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:819)
| at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:782)
| at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:766)
| at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
| at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
| at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
| at java.lang.reflect.Method.invoke(Method.java:585)
| at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
| at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
| at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
| at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
| at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
| at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
| at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
| at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
| at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
| at $Proxy5.deploy(Unknown Source)
| at org.jboss.system.server.ServerImpl.doStart(ServerImpl.java:482)
| at org.jboss.system.server.ServerImpl.start(ServerImpl.java:362)
| at org.jboss.Main.boot(Main.java:200)
| at org.jboss.Main$1.run(Main.java:508)
| at java.lang.Thread.run(Thread.java:595)
| Caused by: java.sql.BatchUpdateException: Batch-Eintrag 0 insert into jbp_cms_version_node (NODE_ID, NODE_DATA, PK) values (deadbeef-face-babe-cafe-babecafebabe, <stream of 109 bytes>, 30) wurde abgebrochen. Rufen Sie 'getNextException' auf, um die Ursache zu erfahren.
| at org.postgresql.jdbc2.AbstractJdbc2Statement$BatchResultHandler.handleError(AbstractJdbc2Statement.java:2537)
| at org.postgresql.core.v3.QueryExecutorImpl.processResults(QueryExecutorImpl.java:1328)
| at org.postgresql.core.v3.QueryExecutorImpl.execute(QueryExecutorImpl.java:351)
| at org.postgresql.jdbc2.AbstractJdbc2Statement.executeBatch(AbstractJdbc2Statement.java:2674)
| at org.jboss.resource.adapter.jdbc.WrappedStatement.executeBatch(WrappedStatement.java:774)
| at org.hibernate.jdbc.BatchingBatcher.doExecuteBatch(BatchingBatcher.java:48)
| at org.hibernate.jdbc.AbstractBatcher.executeBatch(AbstractBatcher.java:246)
| ... 155 more
|
|
The tables in the database look ok since they have the same types (oid) as in portal 2.6 (which works fine with postgres using the same VM and driver-jar postgresql-8.3-603.jdbc3.jar).
Thanks for helping, Daniel
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4176125#4176125
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4176125
17 years, 6 months
[Design of JBoss ESB] - Re: ESB messages API and design considerations
by karypid
You are correct to point out that all these things are in the Programmer's Manual:
The fact that the actual format of the message ends up as either XML or Java (page 28): anonymous wrote : As mentioned previously, JBossESB supports two serialized message formats: MessageType.JBOSS_XML and MessageType.JAVA_SERIALIZED. In the following sections we shall look at each of these formats in more detail.
The fact that TextBody, ObjectBody et al are not accessible as the "default location" (page 23): anonymous wrote : It is important to realise that these extensions do not store their data in the default location; data should be retrieved using the corresponding getters on the extension instance.
The fact that everything else expects the data in the "default location" (page 22): anonymous wrote : By default, all JBossESB 4.2.1GA+ components (Actions, Listeners, Gateways, Routers, Notifiers etc) get and set data on the message through the messages "Default Payload Location"
The fact that MessageFactory is abstract (page 27): anonymous wrote : public abstract class MessageFactory { ...
I'm just trying to say that these questions remain even after reading the documentation, going through the examples that ship with the ESB (which are VERY useful by the way) and going through the forum reading posts like:
http://www.jboss.com/index.html?module=bb&op=viewtopic&t=116278
http://www.jboss.com/index.html?module=bb&op=viewtopic&t=116445
To an inexperienced user, it is not clear how to approach the subjecto of "message" definition.
I was sidetracked on MessageFactory being abstract because I called its static getInstance() method and got a reference ot something that could create messages. See http://www.jboss.com/index.html?module=bb&op=viewtopic&t=142011 for how I came to do that.
>From what you said, it appears to me that the API was recently fluctuating and that now it is best (in my case where messages are XML documents) to go with XMLMessageFactory, use an appropriate body extension (e.g. TextBody) and write my own actions rather than going with the defaults.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4176103#4176103
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4176103
17 years, 6 months
[Design of JBoss ESB] - Re: ESB messages API and design considerations
by mark.little＠jboss.com
"karypid" wrote : I'm a newcomer to JBossESB and am having trouble understanding the API and rationale behind message factories and the body. I would appreciate some feedback to these very basic questions:
|
| I set a breakpoint in my message composer code and using the variable inspector I observed that:
|
You know the code is available to look through too :-) ?
anonymous wrote :
|
| When you use the XMLMessageFactory to create a text message, it creates an entry in the table of objects that belong to the message body. The key used is "org.jboss.soa.esb.message.payload.text", which is the constant value for TextBody.DEFAULT_LOCATION.
| If you simply use a MessageFactory, an entry is created in the message objects table under the key Body.DEFAULT_LOCATION (whose value is "org.jboss.soa.esb.message.defaultEntry").
|
|
Yes, plus this is all documented in the Programmers Guide.
anonymous wrote :
| Now, all actions that pre-ship with the JBoss ESB expect the message body to reside at Body.DEFAULT_LOCATION. So, if you create your message using an XMLMessageFactory, all these goodies are useless, because they can't "see" your message body.
|
These factories and body types were added quite late in the development of the 4.x codebase, primarily as a way of trying to simplify the whole message approach. However, we ended up simplifying the message interaction in another way entirely, so none of the out-of-the-box actions make use of them. But that's not to say that you can't create your own actions that use them. Once again, that's kind of the benefit of having the source or having a pluggable architecture for service composition: if you don't like what you get then you can replace/augment it.
anonymous wrote :
| My understanding was that the basic things you need to decide in order to create your message, are:
|
| The kind of serialization you want to use withing the ESB: this means you must choose either XMLMessageFactory or SerializedMessageFactory.
| What will be in the message body. This means that you must choose a TextBody, ObjectBody, BytesBody, or MapBody).
|
Have you checked out the Programmers Guide? As I said, it does go into this in some detail.
But the majority illustrations and examples for message interaction is not to go via these Body types at all. That's not to say that you have to develop in that way yourself. But as you've pointed out, the out-of-the-box actions won't be keying on the same points in the payload.
anonymous wrote :
| So, here's the list of things that don't make sense:
|
| Why is MessageFactory non-abstract? Shouldn't one be forced to use XML / Java serialization (or roll their own)? I would've expected it to be abstract and for XMLMessageFactory and SerializedMessageFactory to extend it. If you want some other serialization, you would need to extend MessageFactory and implement the message construction methods.
|
Erm, MessageFactory is abstract.
| public abstract class MessageFactory
|
anonymous wrote :
| Since MessageFactory is (evidently) non-abstract, what serialization does it use?
|
It's evidently abstract ;-) Which code are you looking at?
anonymous wrote :
| I would've expected the message factories (XMLMessageFactory and SerializedMessageFactory) to place the body under the Body.DEFAULT_LOCATION key. Why don't they do that?
|
The current approach is to put the content in a well-defined location within the payload that isn't the DEFAULT_LOCATION in order that they can co-exist with existing code.
anonymous wrote :
| In fact, what's the point of having various message body types (TextBody, ObjectBody, etc)? Is it to improve legibility of the code? (admittedly, writing "TextBody" immediately reveals to the developer reading it what one is working with text here)
|
The request we had at the time was a suggestion to mirror the JMS message types, since many users know and understand that approach.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4176096#4176096
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4176096
17 years, 6 months