7 Replies Latest reply on Mar 12, 2015 8:40 PM by George Bogdan

    Configuring VFS in jBPM 6.1.0.Final Console to use the file system instead of the default git

    George Bogdan Newbie

      Hello,

       

      How can be the VFS in jBPM 6.1.0.Final KIE web console configured to use the local file system instead of the default git.

       

      Best regards,

      George Bogdan

        • 1. Re: Configuring VFS in jBPM 6.1.0.Final Console to use the file system instead of the default git
          Maciej Swiderski Master

          while 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

          1 of 1 people found this helpful
          • 2. Re: Configuring VFS in jBPM 6.1.0.Final Console to use the file system instead of the default git
            George Bogdan Newbie

            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
              Maciej Swiderski Master

              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 Newbie

                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
                  Maciej Swiderski Master

                  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 Newbie

                    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 Newbie

                      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