CMDBuild Forum

Shark Configuration Issues

Old Versions
#1

I've installed CMDBuild-2.2/2.2.1 on Debian 7.6. I am using Tomcat7 and the most recent version of PostgreSQL (9.3.x.x). Getting CMDBuild up and running wasn't a problem but I do have some concerns over the CMDBuild Shark setup. I'll walk you through my procedure to verify if I'm making any mistakes. I am being explicit, if I didn't write it, I didn't do it.

 

1) I install CMDBuild by deploying the CMDBuild.war file using the Tomcat Manager GUI.

 

2) I install CMDBuild-Shark by deploying the CMDBuild-Shark.war file using the Tomcat Manager GUI.

 

This is what my configuration now looks like in Tomcat: http://i.imgur.com/MXlg2nl.png

 

3) I open CMDBuild (localhost:8080/cmdbuild) and follow through the configuration. I select an empty Database, name it "cmdbuild" and CHECK the box to create Shark Schema.  The configuration finishes and I login.

 

4) I shut down the Tomcat7 service.

 

5) I edit (/var/lib/tomcat7/webapps/cmdbuild-shark/META-INF/context.xml) per the manual. I change the URL to represent my database name. I don't change any other value. Screenshot: http://i.imgur.com/2Rw7g3D.png

 

6) I edit (/var/lib/tomcat7/webapps/cmdbuild-shark/conf/Shark.conf) per the manual. I change the org.cmdbuild.ws.url setting to equal my CMDBuild site address. I leave the usename and password as they were. I don't change anything else. Screenshot: http://i.imgur.com/cjkWEou.png

 

7) I edit (/var/lib/tomcat7/webapps/cmdbuild/WEB-INF/conf/auth.conf). I remove the comment from the line: serviceusers.prigileged=workflow. Screenshot: http://i.imgur.com/SAgIV0H.png

 

8) I start the Tomcat Server using sudo /etc/init.d/tomcat7 start.

 

9) I log in and enable the Workflow server and give it my url of my Shark deployment. I do not change the username or password. Screenshot: http://i.imgur.com/jfDon7U.png

 

10) I create a user named "workflow" with the password "changeme". This matches the default values for username and password in the Shark.conf file. Screenshot: http://i.imgur.com/IcK3eYx.png

 

According to the technical manual I should be done, but this doesn't seem to work. I don't see the Workflow option appear. When I did this same procedure with the demo database which I believe has a demo workflow, it didn't work either. Am I missing steps? Did I forget to configure or do something?

 

Any help or information would be greatly appreciated.

#2
Dear Tommy,
it looks like you have followed all the steps correctly. I have seen from your screenshot that you do have the "Processes" tab enabled in the administration module of CMDBuild, if you don't see the "Processes" tab in the Management module, it might be only because you don't have any process defined yet! You will see the tab in the management module only once you have created at least one process and uploaded an xpdl file for that process.
 
Regarding the same procedure with the demo database, did you uploaded the xpdl file that comes with the release? If you didn't you should see an error when you enter and you don't see the "Processes" tab but you will see it once you upload the xpdl file.
I hope this answer could help you.
Regards,
 
Support Team
 
 
 
Previously Tommy wrote:

I've installed CMDBuild-2.2/2.2.1 on Debian 7.6. I am using Tomcat7 and the most recent version of PostgreSQL (9.3.x.x). Getting CMDBuild up and running wasn't a problem but I do have some concerns over the CMDBuild Shark setup. I'll walk you through my procedure to verify if I'm making any mistakes. I am being explicit, if I didn't write it, I didn't do it.

 

1) I install CMDBuild by deploying the CMDBuild.war file using the Tomcat Manager GUI.

 

2) I install CMDBuild-Shark by deploying the CMDBuild-Shark.war file using the Tomcat Manager GUI.

 

This is what my configuration now looks like in Tomcat: http://i.imgur.com/MXlg2nl.png

 

3) I open CMDBuild (localhost:8080/cmdbuild) and follow through the configuration. I select an empty Database, name it "cmdbuild" and CHECK the box to create Shark Schema.  The configuration finishes and I login.

 

4) I shut down the Tomcat7 service.

 

5) I edit (/var/lib/tomcat7/webapps/cmdbuild-shark/META-INF/context.xml) per the manual. I change the URL to represent my database name. I don't change any other value. Screenshot: http://i.imgur.com/2Rw7g3D.png

 

6) I edit (/var/lib/tomcat7/webapps/cmdbuild-shark/conf/Shark.conf) per the manual. I change the org.cmdbuild.ws.url setting to equal my CMDBuild site address. I leave the usename and password as they were. I don't change anything else. Screenshot: http://i.imgur.com/cjkWEou.png

 

7) I edit (/var/lib/tomcat7/webapps/cmdbuild/WEB-INF/conf/auth.conf). I remove the comment from the line: serviceusers.prigileged=workflow. Screenshot: http://i.imgur.com/SAgIV0H.png

 

8) I start the Tomcat Server using sudo /etc/init.d/tomcat7 start.

 

9) I log in and enable the Workflow server and give it my url of my Shark deployment. I do not change the username or password. Screenshot: http://i.imgur.com/jfDon7U.png

 

10) I create a user named "workflow" with the password "changeme". This matches the default values for username and password in the Shark.conf file. Screenshot: http://i.imgur.com/IcK3eYx.png

 

According to the technical manual I should be done, but this doesn't seem to work. I don't see the Workflow option appear. When I did this same procedure with the demo database which I believe has a demo workflow, it didn't work either. Am I missing steps? Did I forget to configure or do something?

 

Any help or information would be greatly appreciated.

 

#3

I think I may be having a similar issue.

 

:ERROR: relation "shkresourcestable" does not exist

 

I check the DB and after the initial shark installation there were no tables created.

I used the sql script provided and created them but still get the same error.

 

 

cmdbuild=# \dt shkresourcestable

               List of relations

 Schema |       Name        | Type  |  Owner

--------+-------------------+-------+----------

 public | shkresourcestable | table | postgres

(1 row)

 

 

#4

Shark tables must be created in the “shark” schema, not in the “public” schema.
CMDBuild Team

 

 

#5

Thank you for the help but I still have a problem. I tried this again with the demo database, repeating the procedure on a clean install of Debian with Tomcat7 and Postgre 9.1. When I attempt to access the processes tab which contains the premade "request for change" process, I get an error, as show below. When I attempted to upload, I get the error: Call: services/json/workflow/uploadxpdl

 

Any ideas? I tried to search and trace but it simply seems Shark isn't communicatin with CMDBuild.

 

Call: services/json/workflow/xpdlversions
------------------------------------------
Error: org.cmdbuild.workflow.CMWorkflowException: java.lang.NullPointerException
	at org.cmdbuild.workflow.service.TransactedSharkService$TransactedExecutor.initAndConnect(TransactedSharkService.java:49)
	at org.cmdbuild.workflow.service.TransactedSharkService$TransactedExecutor.execute(TransactedSharkService.java:23)
	at org.cmdbuild.workflow.service.TransactedSharkService.downloadAllPackages(TransactedSharkService.java:127)
	at org.cmdbuild.workflow.xpdl.CachedProcessDefinitionStore$LazyClassNameToPackageInfoMap.fetchProcessDefinitions(CachedProcessDefinitionStore.java:119)
	at org.cmdbuild.workflow.xpdl.CachedProcessDefinitionStore$LazyClassNameToPackageInfoMap.checkLoaded(CachedProcessDefinitionStore.java:111)
	at org.cmdbuild.workflow.xpdl.CachedProcessDefinitionStore$LazyClassNameToPackageInfoMap.getPackageInfoByClass(CachedProcessDefinitionStore.java:98)
	at org.cmdbuild.workflow.xpdl.CachedProcessDefinitionStore.getPackageId(CachedProcessDefinitionStore.java:209)
	at org.cmdbuild.workflow.xpdl.CachedProcessDefinitionStore.getPackageVersions(CachedProcessDefinitionStore.java:204)
	at org.cmdbuild.workflow.xpdl.AbstractProcessDefinitionManager.getVersions(AbstractProcessDefinitionManager.java:37)
	at org.cmdbuild.workflow.ProcessClassImpl.getDefinitionVersions(ProcessClassImpl.java:167)
	at org.cmdbuild.logic.workflow.DefaultWorkflowLogic.getProcessDefinitionVersions(DefaultWorkflowLogic.java:456)
	at org.cmdbuild.servlets.json.Workflow.xpdlVersions(Workflow.java:238)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:622)
	at org.cmdbuild.servlets.JSONDispatcher.dispatch(JSONDispatcher.java:97)
	at org.cmdbuild.servlets.JSONDispatcher.doPost(JSONDispatcher.java:57)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:641)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:722)
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:305)
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
	at org.cmdbuild.filters.AuthFilter.doFilter(AuthFilter.java:158)
	at org.springframework.web.filter.DelegatingFilterProxy.invokeDelegate(DelegatingFilterProxy.java:346)
	at org.springframework.web.filter.DelegatingFilterProxy.doFilter(DelegatingFilterProxy.java:259)
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243)
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
	at org.cmdbuild.filters.PatchManagerFilter.doFilter(PatchManagerFilter.java:48)
	at org.springframework.web.filter.DelegatingFilterProxy.invokeDelegate(DelegatingFilterProxy.java:346)
	at org.springframework.web.filter.DelegatingFilterProxy.doFilter(DelegatingFilterProxy.java:259)
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243)
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
	at org.cmdbuild.filters.ConfCheckFilter.doFilter(ConfCheckFilter.java:31)
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243)
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
	at org.cmdbuild.filters.TranslationFilter.doFilter(TranslationFilter.java:52)
	at org.springframework.web.filter.DelegatingFilterProxy.invokeDelegate(DelegatingFilterProxy.java:346)
	at org.springframework.web.filter.DelegatingFilterProxy.doFilter(DelegatingFilterProxy.java:259)
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243)
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
	at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:225)
	at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:123)
	at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:472)
	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:168)
	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:98)
	at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:927)
	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118)
	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:407)
	at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1002)
	at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:579)
	at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:312)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1146)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
	at java.lang.Thread.run(Thread.java:701)
Caused by: java.lang.NullPointerException
	at org.apache.axis.message.SOAPFaultBuilder.createFault(SOAPFaultBuilder.java:222)
	at org.apache.axis.message.SOAPFaultBuilder.endElement(SOAPFaultBuilder.java:129)
	at org.apache.axis.encoding.DeserializationContext.endElement(DeserializationContext.java:1087)
	at org.apache.xerces.parsers.AbstractSAXParser.endElement(Unknown Source)
	at org.apache.xerces.impl.XMLNSDocumentScannerImpl.scanEndElement(Unknown Source)
	at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown Source)
	at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown Source)
	at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
	at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
	at org.apache.xerces.parsers.XMLParser.parse(Unknown Source)
	at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source)
	at org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser.parse(Unknown Source)
	at org.apache.xerces.jaxp.SAXParserImpl.parse(Unknown Source)
	at org.apache.axis.encoding.DeserializationContext.parse(DeserializationContext.java:227)
	at org.apache.axis.SOAPPart.getAsSOAPEnvelope(SOAPPart.java:696)
	at org.apache.axis.Message.getSOAPEnvelope(Message.java:435)
	at org.apache.axis.handlers.soap.MustUnderstandChecker.invoke(MustUnderstandChecker.java:62)
	at org.apache.axis.client.AxisClient.invoke(AxisClient.java:206)
	at org.apache.axis.client.Call.invokeEngine(Call.java:2784)
	at org.apache.axis.client.Call.invoke(Call.java:2767)
	at org.apache.axis.client.Call.invoke(Call.java:2443)
	at org.apache.axis.client.Call.invoke(Call.java:2366)
	at org.apache.axis.client.Call.invoke(Call.java:1812)
	at org.enhydra.shark.ejb.client.ws.WAPIEJBEndpointPortSoapBindingStub.connect(Unknown Source)
	at org.cmdbuild.workflow.service.TransactedSharkService$TransactedExecutor.initAndConnect(TransactedSharkService.java:46)
	... 53 more

 

 

Previously Support wrote:
Dear Tommy,
it looks like you have followed all the steps correctly. I have seen from your screenshot that you do have the "Processes" tab enabled in the administration module of CMDBuild, if you don't see the "Processes" tab in the Management module, it might be only because you don't have any process defined yet! You will see the tab in the management module only once you have created at least one process and uploaded an xpdl file for that process.
 
Regarding the same procedure with the demo database, did you uploaded the xpdl file that comes with the release? If you didn't you should see an error when you enter and you don't see the "Processes" tab but you will see it once you upload the xpdl file.
I hope this answer could help you.
Regards,
 
Support Team
#6

Thanks, they weren't created at all was the problem. Also as a note: the 01_shark_user.sql for creating the user has the part to create the shark scheme commented out so you have to manually do it if you try and run the sql script.

#7

I managed to fix the problem. First, I forced Tomcat7 to run as root. Next, I changed the owner of the Shark schema in the DB to the shark user. It was previously owned by the postgres user. I did this in PGAdmin, or whatever the GUI for PSQL is called. Next I made sure my Workflow user was only tied to one user group in the users model of CMDBuild. Now it works.

 

I will look further into why Shark needs Tomcat to run as root. I don't like that idea. Java is insecure enough as it is.

 

Previously Tecnoteca wrote:
Shark tables must be created in the "shark" schema, not in the "public" schema.
CMDBuild Team