-
1. Re: Configuring VFS in jBPM 6.1.0.Final Console to use the file system instead of the default git
swiderski.maciej Nov 27, 2014 1:50 AM (in response to george_bogdan)1 of 1 people found this helpfulwhile VFS does support simple file system as backend kie-wb currently requires git as it operates on git repositories for their knowledge archives and version control. That is essential to kie-wb functionaltiy thus using only file system would not satisfy quality measures.
You can give it a try any whay by modifying file org.uberfire.java.nio.file.spi.FileSystemProvider that is stored in kie-wb/WEB-INF/classes/META-INF/services. Disable JGit file system provider. Make sure you disable git services (over git and ssh protocol) vis system properties
HTH
-
2. Re: Configuring VFS in jBPM 6.1.0.Final Console to use the file system instead of the default git
george_bogdan Dec 11, 2014 10:34 PM (in response to swiderski.maciej)Hi Maciej,
Thank you for your reply. The project I am working on is using SVN for repository and moving on to Git is not an option in the near future. I need to use the file system directly in order to have the jBPM artifacts under SVN version control. Is there another way to configure jBPM to use SVN?
As per your instructions I have modified org.uberfire.java.nio.file.spi.FileSystemProvider. To disable git services I need to set the 2 system properties below to false or there are more:
org.uberfire.nio.git.daemon.enabled=false
org.uberfire.nio.git.ssh.enabled=false
Your help with this is really appreciated.
Best regards,
George Bogdan
-
3. Re: Configuring VFS in jBPM 6.1.0.Final Console to use the file system instead of the default git
swiderski.maciej Dec 12, 2014 1:57 AM (in response to george_bogdan)George,
look at the git svn bridge that can actually allow you to synchronize assets in both repositories which should allow you to run jbpm with default git backend and still utilize your regular SVN in same way as you don now.
HTH
-
4. Re: Configuring VFS in jBPM 6.1.0.Final Console to use the file system instead of the default git
george_bogdan Dec 12, 2014 7:52 PM (in response to swiderski.maciej)Hi Maciej,
Thank you again for your reply. Git-SVN bridge is certainly an option though we prefer to use SVN if possible, same with the other project modules, the development workflow is cleaner and so is the build and change management process.
Are the properties below the ones that need to be set up to use the file system directly or there are more:
org.uberfire.nio.git.daemon.enabled=false
org.uberfire.nio.git.ssh.enabled=false
Best regards,
George Bogdan
-
5. Re: Configuring VFS in jBPM 6.1.0.Final Console to use the file system instead of the default git
swiderski.maciej Dec 15, 2014 1:52 AM (in response to george_bogdan)yes, that should be pretty much it. Assuming you have changed the services file that defines what providers are available.
Anyway, with simple file system access you will loose all history and version control (revert in case of invalid changes). So putting svb git bridge might be valid choice in the end...
HTH
-
6. Re: Configuring VFS in jBPM 6.1.0.Final Console to use the file system instead of the default git
george_bogdan Dec 18, 2014 11:24 AM (in response to swiderski.maciej)Hi Maciej,
I understand the downsides of not using git, but at this time SVN is the best option for our project. I have changed the services file:
org.uberfire.java.nio.fs.file.SimpleFileSystemProvider
# org.uberfire.java.nio.fs.jgit.JGitFileSystemProvider
# org.kie.commons.java.nio.fs.eclipse.EclipseFileSystemProvider # eclipse provider
and added this to standalone.xml:
<system-properties>
<property name="org.uberfire.nio.git.daemon.enabled" value="false"/>
<property name="org.uberfire.nio.git.ssh.enabled" value="false"/>
<property name="org.kie.demo" value="false"/>
</system-properties>
but I am getting the errors below upon starting the JBoss AS, can you please assist with this issue?
Best regards,
George Bogdan
10:06:37,058 ERROR [org.jboss.as.server.deployment.scanner] (DeploymentScanner-threads - 1) {"JBAS014653: Composite operation failed and was rolled back. Steps that failed:" => {"Operation step-2" => {"JBAS014671: Failed services" => {"jboss.deployment.unit.\"kie-wb.war\".WeldService" => "org.jboss.msc.service.StartException in service jboss.deployment.unit.\"kie-wb.war\".WeldService: org.jboss.weld.exceptions.DeploymentException: Exception List with 1 exceptions:
Exception 0 :
org.jboss.weld.exceptions.WeldException: WELD-000049 Unable to invoke [method] @PostConstruct public org.kie.workbench.backend.AppSetup.assertPlayground() on org.kie.workbench.backend.AppSetup@2ce0127d
at org.jboss.weld.bean.AbstractClassBean.defaultPostConstruct(AbstractClassBean.java:518)
at org.jboss.weld.bean.ManagedBean$ManagedBeanInjectionTarget.postConstruct(ManagedBean.java:174)
at org.jboss.weld.bean.ManagedBean.create(ManagedBean.java:291)
at org.jboss.weld.context.AbstractContext.get(AbstractContext.java:107)
at org.jboss.weld.bean.proxy.ContextBeanInstance.getInstance(ContextBeanInstance.java:90)
at org.jboss.weld.bean.proxy.ProxyMethodHandler.invoke(ProxyMethodHandler.java:79)
at org.kie.workbench.backend.AppSetup$Proxy$_$$_WeldClientProxy.toString(AppSetup$Proxy$_$$_WeldClientProxy.java)
at org.uberfire.commons.services.cdi.StartupBeanExtension.runPostConstruct(StartupBeanExtension.java:83)
at org.uberfire.commons.services.cdi.StartupBeanExtension.afterDeploymentValidation(StartupBeanExtension.java:67)
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:606)
at org.jboss.weld.util.reflection.SecureReflections$13.work(SecureReflections.java:264)
at org.jboss.weld.util.reflection.SecureReflectionAccess.run(SecureReflectionAccess.java:52)
at org.jboss.weld.util.reflection.SecureReflectionAccess.runAsInvocation(SecureReflectionAccess.java:137)
at org.jboss.weld.util.reflection.SecureReflections.invoke(SecureReflections.java:260)
at org.jboss.weld.introspector.jlr.WeldMethodImpl.invokeOnInstance(WeldMethodImpl.java:170)
at org.jboss.weld.introspector.ForwardingWeldMethod.invokeOnInstance(ForwardingWeldMethod.java:51)
at org.jboss.weld.injection.MethodInjectionPoint.invokeOnInstanceWithSpecialValue(MethodInjectionPoint.java:154)
at org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:241)
at org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:229)
at org.jboss.weld.event.ObserverMethodImpl.notify(ObserverMethodImpl.java:207)
at org.jboss.weld.bootstrap.events.AbstractContainerEvent.fire(AbstractContainerEvent.java:75)
at org.jboss.weld.bootstrap.events.AbstractDeploymentContainerEvent.fire(AbstractDeploymentContainerEvent.java:46)
at org.jboss.weld.bootstrap.events.AfterDeploymentValidationImpl.fire(AfterDeploymentValidationImpl.java:31)
at org.jboss.weld.bootstrap.WeldBootstrap.validateBeans(WeldBootstrap.java:369)
at org.jboss.as.weld.WeldContainer.start(WeldContainer.java:83)
at org.jboss.as.weld.services.WeldService.start(WeldService.java:76)
at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1811)
at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1746)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:745)
Caused by: java.lang.reflect.InvocationTargetException
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:606)
at org.jboss.weld.util.reflection.SecureReflections$13.work(SecureReflections.java:264)
at org.jboss.weld.util.reflection.SecureReflectionAccess.run(SecureReflectionAccess.java:52)
at org.jboss.weld.util.reflection.SecureReflectionAccess.runAsInvocation(SecureReflectionAccess.java:137)
at org.jboss.weld.util.reflection.SecureReflections.invoke(SecureReflections.java:260)
at org.jboss.weld.introspector.jlr.WeldMethodImpl.invoke(WeldMethodImpl.java:174)
at org.jboss.weld.bean.AbstractClassBean.defaultPostConstruct(AbstractClassBean.java:516)
... 33 more
Caused by: org.jboss.weld.exceptions.WeldException: WELD-000049 Unable to invoke [method] @PostConstruct public org.uberfire.backend.server.config.ConfigurationServiceImpl.setup() on org.uberfire.backend.server.config.ConfigurationServiceImpl@3a764d97
at org.jboss.weld.bean.AbstractClassBean.defaultPostConstruct(AbstractClassBean.java:518)
at org.jboss.weld.bean.ManagedBean$ManagedBeanInjectionTarget.postConstruct(ManagedBean.java:174)
at org.jboss.weld.bean.ManagedBean.create(ManagedBean.java:291)
at org.jboss.weld.context.AbstractContext.get(AbstractContext.java:107)
at org.jboss.weld.bean.proxy.ContextBeanInstance.getInstance(ContextBeanInstance.java:90)
at org.jboss.weld.bean.proxy.ProxyMethodHandler.invoke(ProxyMethodHandler.java:79)
at org.uberfire.backend.server.config.ConfigurationServiceImpl$Proxy$_$$_WeldClientProxy.getConfiguration(ConfigurationServiceImpl$Proxy$_$$_WeldClientProxy.java)
at org.kie.workbench.backend.AppSetup.assertPlayground(AppSetup.java:129)
... 43 more
Caused by: java.lang.reflect.InvocationTargetException
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:606)
at org.jboss.weld.util.reflection.SecureReflections$13.work(SecureReflections.java:264)
at org.jboss.weld.util.reflection.SecureReflectionAccess.run(SecureReflectionAccess.java:52)
at org.jboss.weld.util.reflection.SecureReflectionAccess.runAsInvocation(SecureReflectionAccess.java:137)
at org.jboss.weld.util.reflection.SecureReflections.invoke(SecureReflections.java:260)
at org.jboss.weld.introspector.jlr.WeldMethodImpl.invoke(WeldMethodImpl.java:174)
at org.jboss.weld.bean.AbstractClassBean.defaultPostConstruct(AbstractClassBean.java:516)
... 50 more
Caused by: org.uberfire.java.nio.file.FileSystemNotFoundException: Provider 'git' not found
at org.uberfire.java.nio.file.api.FileSystemProviders.getProvider(FileSystemProviders.java:114)
at org.uberfire.java.nio.file.api.FileSystemProviders.resolveProvider(FileSystemProviders.java:104)
at org.uberfire.java.nio.file.FileSystems.newFileSystem(FileSystems.java:117)
at org.uberfire.java.nio.file.FileSystems.newFileSystem(FileSystems.java:83)
at org.uberfire.io.impl.AbstractIOService.newFileSystem(AbstractIOService.java:261)
at org.uberfire.backend.server.config.ConfigurationServiceImpl.setup(ConfigurationServiceImpl.java:96)
... 60 more
"}}}}
10:06:37,075 ERROR [org.jboss.as.server.deployment.scanner] (DeploymentScanner-threads - 1) JBAS014654: Composite operation was rolled back
-
7. Re: Configuring VFS in jBPM 6.1.0.Final Console to use the file system instead of the default git
george_bogdan Mar 12, 2015 8:40 PM (in response to george_bogdan)Hi Maciej,
Just to close this thread - using the KIE console with SVN did not work, we ended up using the Eclipse BPMN2 Editor for editing the BPMN2 process diagrams. Thank you for your help.
Best regards,
George Bogdan