[JBoss JIRA] (DROOLS-2350) Kie WB REST clone operation does not do migration
by Jakub Schwan (JIRA)
[ https://issues.jboss.org/browse/DROOLS-2350?page=com.atlassian.jira.plugi... ]
Jakub Schwan commented on DROOLS-2350:
--------------------------------------
[~Rikkola] We need to fix this. We are having a lot of failing jobs because we are not able to work with cloned projects.
> Kie WB REST clone operation does not do migration
> -------------------------------------------------
>
> Key: DROOLS-2350
> URL: https://issues.jboss.org/browse/DROOLS-2350
> Project: Drools
> Issue Type: Bug
> Components: build
> Reporter: Jakub Schwan
> Assignee: Toni Rikkola
> Priority: Blocker
> Labels: appformer, reported-by-qe
>
> Repository can be cloned to workbench via UI or REST. When is cloned repository via REST endpoint with more projects and repository has old format, then this repository is cloned to workbench, but it is not migrated to new format, so in Workbench is thrown error dialog and data copied from repo are not visible.
> Old structure of repositories is not supported. But we are able to clone old repos into the workbench via UI. The problem is the REST clone operation does not do migration.
> So if there is no pom.xml file in the root of the repository that is migrated, then that repository needs to be migrated before cloning. Or optionally you clone everything in and then migrate.
> We can do migration when we clone. Also we should notify users, that by cloning and migrating from old format can be changed their repo structure and they need to migrate their repositories too (or they can commit new one from migrated repos in Workbench).
> Another option can be parent pom for repositories with more porjects, but with this option we do NOT follow Project Oriented changes. (Not tested yet)
> Actual result:
> via REST call are projects indexed and cloned, but in the workbench aren't any project created
> Expected result:
> via REST call are all projects from repository created in Workbench
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (DROOLS-2350) Kie WB REST clone operation does not do migration
by Jakub Schwan (JIRA)
[ https://issues.jboss.org/browse/DROOLS-2350?page=com.atlassian.jira.plugi... ]
Jakub Schwan updated DROOLS-2350:
---------------------------------
Priority: Blocker (was: Major)
> Kie WB REST clone operation does not do migration
> -------------------------------------------------
>
> Key: DROOLS-2350
> URL: https://issues.jboss.org/browse/DROOLS-2350
> Project: Drools
> Issue Type: Bug
> Components: build
> Reporter: Jakub Schwan
> Assignee: Toni Rikkola
> Priority: Blocker
> Labels: appformer, reported-by-qe
>
> Repository can be cloned to workbench via UI or REST. When is cloned repository via REST endpoint with more projects and repository has old format, then this repository is cloned to workbench, but it is not migrated to new format, so in Workbench is thrown error dialog and data copied from repo are not visible.
> Old structure of repositories is not supported. But we are able to clone old repos into the workbench via UI. The problem is the REST clone operation does not do migration.
> So if there is no pom.xml file in the root of the repository that is migrated, then that repository needs to be migrated before cloning. Or optionally you clone everything in and then migrate.
> We can do migration when we clone. Also we should notify users, that by cloning and migrating from old format can be changed their repo structure and they need to migrate their repositories too (or they can commit new one from migrated repos in Workbench).
> Another option can be parent pom for repositories with more porjects, but with this option we do NOT follow Project Oriented changes. (Not tested yet)
> Actual result:
> via REST call are projects indexed and cloned, but in the workbench aren't any project created
> Expected result:
> via REST call are all projects from repository created in Workbench
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (DROOLS-2359) DMN DecisionTable output validation when type is a collection
by Matteo Mortari (JIRA)
[ https://issues.jboss.org/browse/DROOLS-2359?page=com.atlassian.jira.plugi... ]
Matteo Mortari updated DROOLS-2359:
-----------------------------------
Description:
Given the following type:
!screenshot-1.png!
and the following Decision Table:
!screenshot-2.png!
it return error because it tries to validate {{["abc", "xyz"]}} as a feel:string type, without awareness of collection.
> DMN DecisionTable output validation when type is a collection
> -------------------------------------------------------------
>
> Key: DROOLS-2359
> URL: https://issues.jboss.org/browse/DROOLS-2359
> Project: Drools
> Issue Type: Bug
> Components: dmn engine
> Reporter: Matteo Mortari
> Assignee: Matteo Mortari
> Attachments: screenshot-1.png, screenshot-2.png
>
>
> Given the following type:
> !screenshot-1.png!
> and the following Decision Table:
> !screenshot-2.png!
> it return error because it tries to validate {{["abc", "xyz"]}} as a feel:string type, without awareness of collection.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (WFLY-9801) Wsprovide tool ends with java.security.AccessControlException
by Alessio Soldano (JIRA)
[ https://issues.jboss.org/browse/WFLY-9801?page=com.atlassian.jira.plugin.... ]
Alessio Soldano resolved WFLY-9801.
-----------------------------------
Fix Version/s: 12.0.0.Final
(was: 13.0.0.Beta1)
Assignee: Alessio Soldano (was: R Searls)
Resolution: Done
Marking as solved in 12.0.0.Final, given the fix was already there before the release was tagged.
> Wsprovide tool ends with java.security.AccessControlException
> -------------------------------------------------------------
>
> Key: WFLY-9801
> URL: https://issues.jboss.org/browse/WFLY-9801
> Project: WildFly
> Issue Type: Bug
> Components: Scripts, Web Services
> Reporter: Marek Kopecký
> Assignee: Alessio Soldano
> Priority: Critical
> Fix For: 12.0.0.Final
>
> Attachments: Echo1-security.policy, Echo1.class, Echo1Impl.class
>
>
> *Description of the issue:*
> wsprovide tool ends with java.security.AccessControlException
> I see this issue on WF master (2018_02_12). This is regression against WF master from 2018_02_05, so priority of this jira is blocker.
> *How reproducible:*
> Always
> *Steps to Reproduce:*
> # Use these (class files are attached):
> {code:java}
> @WebService(endpointInterface = "org.jboss.as.testsuite.integration.scripts.test.tools.Echo1", targetNamespace = "org.jboss.as.testsuite.integration.scripts.test.tools", serviceName = "Echo1Service")
> public class Echo1Impl implements Echo1 {
> @Override
> public String echoPlus1(String s) {
> return s + "1";
> }
> }
> {code}
> {code:java}
> @WebService
> @SOAPBinding
> public interface Echo1 {
> String echoPlus1(String s);
> }
> {code}
> # cd $\{JBOSS_HOME\}/bin
> # mkdir out
> # ./wsprovide.sh -k -c $\{CLASS_DIR\} -o out org.jboss.as.testsuite.integration.scripts.test.tools.Echo1Impl
> *Actual results:*
> {noformat}
> [mkopecky@localhost bin]$ ./wsprovide.sh -k -c ~/erase2 -o out org.jboss.as.testsuite.integration.scripts.test.tools.Echo1Impl
> Could not find log4j.properties or log4j.xml configuration, logging to console.
> java2ws -s /home/mkopecky/playground/wf/wfly.13/wfly.13/bin/out -classdir /home/mkopecky/playground/wf/wfly.13/wfly.13/bin/out -d /home/mkopecky/playground/wf/wfly.13/wfly.13/bin/out -verbose -cp /home/mkopecky/erase2/: -wrapperbean -createxsdimports org.jboss.as.testsuite.integration.scripts.test.tools.Echo1Impl
> java2ws - Apache CXF 3.2.2
> java.security.AccessControlException: access denied ("java.io.FilePermission" "/home/mkopecky/playground/wf/wfly.13/wfly.13/bin/out/org/jboss/as/testsuite/integration/scripts/test/tools/jaxws/EchoPlus1Response.java" "read")
> at java.security.AccessControlContext.checkPermission(AccessControlContext.java:472)
> at java.security.AccessController.checkPermission(AccessController.java:884)
> at java.lang.SecurityManager.checkPermission(SecurityManager.java:549)
> at java.lang.SecurityManager.checkRead(SecurityManager.java:888)
> at java.io.File.isDirectory(File.java:844)
> at com.sun.tools.javac.file.RegularFileObject.<init>(RegularFileObject.java:69)
> at com.sun.tools.javac.file.RegularFileObject.<init>(RegularFileObject.java:64)
> at com.sun.tools.javac.file.JavacFileManager.getJavaFileObjectsFromFiles(JavacFileManager.java:785)
> at com.sun.tools.javac.file.JavacFileManager.getJavaFileObjectsFromStrings(JavacFileManager.java:185)
> at org.apache.cxf.common.util.Compiler.useJava6Compiler(Compiler.java:202)
> at org.apache.cxf.common.util.Compiler.compileFiles(Compiler.java:141)
> at org.apache.cxf.tools.java2wsdl.generator.wsdl11.BeanGenerator.generateAndCompile(BeanGenerator.java:91)
> at org.apache.cxf.tools.java2wsdl.generator.wsdl11.BeanGenerator.generate(BeanGenerator.java:58)
> at org.apache.cxf.tools.java2wsdl.generator.wsdl11.BeanGenerator.generate(BeanGenerator.java:35)
> at org.apache.cxf.tools.java2wsdl.processor.JavaToWSDLProcessor.generate(JavaToWSDLProcessor.java:156)
> at org.apache.cxf.tools.java2wsdl.processor.JavaToWSDLProcessor.process(JavaToWSDLProcessor.java:118)
> at org.apache.cxf.tools.java2ws.JavaToWSContainer.processWSDL(JavaToWSContainer.java:110)
> at org.apache.cxf.tools.java2ws.JavaToWSContainer.execute(JavaToWSContainer.java:75)
> at org.apache.cxf.tools.common.toolspec.ToolRunner.runTool(ToolRunner.java:105)
> at org.apache.cxf.tools.common.toolspec.ToolRunner.runTool(ToolRunner.java:45)
> at org.apache.cxf.tools.java2ws.JavaToWS.run(JavaToWS.java:83)
> at org.jboss.wsf.stack.cxf.tools.CXFProviderImpl.provide(CXFProviderImpl.java:200)
> at org.jboss.wsf.stack.cxf.tools.CXFProviderImpl.provide(CXFProviderImpl.java:109)
> at org.jboss.ws.tools.cmd.WSProvide.generate(WSProvide.java:223)
> at org.jboss.ws.tools.cmd.WSProvide.main(WSProvide.java:89)
> at org.jboss.modules.Module.runMainMethod(Module.java:348)
> at org.jboss.modules.Module.run(Module.java:328)
> at org.jboss.modules.Main.main(Main.java:557)
> {noformat}
> *Expected results:*
> No errors
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (WFLY-9801) Wsprovide tool ends with java.security.AccessControlException
by Marek Kopecký (JIRA)
[ https://issues.jboss.org/browse/WFLY-9801?page=com.atlassian.jira.plugin.... ]
Marek Kopecký commented on WFLY-9801:
-------------------------------------
[~asoldano]: I verify this issue, it is fixed. Thank you.
> Wsprovide tool ends with java.security.AccessControlException
> -------------------------------------------------------------
>
> Key: WFLY-9801
> URL: https://issues.jboss.org/browse/WFLY-9801
> Project: WildFly
> Issue Type: Bug
> Components: Scripts, Web Services
> Reporter: Marek Kopecký
> Assignee: R Searls
> Priority: Critical
> Fix For: 13.0.0.Beta1
>
> Attachments: Echo1-security.policy, Echo1.class, Echo1Impl.class
>
>
> *Description of the issue:*
> wsprovide tool ends with java.security.AccessControlException
> I see this issue on WF master (2018_02_12). This is regression against WF master from 2018_02_05, so priority of this jira is blocker.
> *How reproducible:*
> Always
> *Steps to Reproduce:*
> # Use these (class files are attached):
> {code:java}
> @WebService(endpointInterface = "org.jboss.as.testsuite.integration.scripts.test.tools.Echo1", targetNamespace = "org.jboss.as.testsuite.integration.scripts.test.tools", serviceName = "Echo1Service")
> public class Echo1Impl implements Echo1 {
> @Override
> public String echoPlus1(String s) {
> return s + "1";
> }
> }
> {code}
> {code:java}
> @WebService
> @SOAPBinding
> public interface Echo1 {
> String echoPlus1(String s);
> }
> {code}
> # cd $\{JBOSS_HOME\}/bin
> # mkdir out
> # ./wsprovide.sh -k -c $\{CLASS_DIR\} -o out org.jboss.as.testsuite.integration.scripts.test.tools.Echo1Impl
> *Actual results:*
> {noformat}
> [mkopecky@localhost bin]$ ./wsprovide.sh -k -c ~/erase2 -o out org.jboss.as.testsuite.integration.scripts.test.tools.Echo1Impl
> Could not find log4j.properties or log4j.xml configuration, logging to console.
> java2ws -s /home/mkopecky/playground/wf/wfly.13/wfly.13/bin/out -classdir /home/mkopecky/playground/wf/wfly.13/wfly.13/bin/out -d /home/mkopecky/playground/wf/wfly.13/wfly.13/bin/out -verbose -cp /home/mkopecky/erase2/: -wrapperbean -createxsdimports org.jboss.as.testsuite.integration.scripts.test.tools.Echo1Impl
> java2ws - Apache CXF 3.2.2
> java.security.AccessControlException: access denied ("java.io.FilePermission" "/home/mkopecky/playground/wf/wfly.13/wfly.13/bin/out/org/jboss/as/testsuite/integration/scripts/test/tools/jaxws/EchoPlus1Response.java" "read")
> at java.security.AccessControlContext.checkPermission(AccessControlContext.java:472)
> at java.security.AccessController.checkPermission(AccessController.java:884)
> at java.lang.SecurityManager.checkPermission(SecurityManager.java:549)
> at java.lang.SecurityManager.checkRead(SecurityManager.java:888)
> at java.io.File.isDirectory(File.java:844)
> at com.sun.tools.javac.file.RegularFileObject.<init>(RegularFileObject.java:69)
> at com.sun.tools.javac.file.RegularFileObject.<init>(RegularFileObject.java:64)
> at com.sun.tools.javac.file.JavacFileManager.getJavaFileObjectsFromFiles(JavacFileManager.java:785)
> at com.sun.tools.javac.file.JavacFileManager.getJavaFileObjectsFromStrings(JavacFileManager.java:185)
> at org.apache.cxf.common.util.Compiler.useJava6Compiler(Compiler.java:202)
> at org.apache.cxf.common.util.Compiler.compileFiles(Compiler.java:141)
> at org.apache.cxf.tools.java2wsdl.generator.wsdl11.BeanGenerator.generateAndCompile(BeanGenerator.java:91)
> at org.apache.cxf.tools.java2wsdl.generator.wsdl11.BeanGenerator.generate(BeanGenerator.java:58)
> at org.apache.cxf.tools.java2wsdl.generator.wsdl11.BeanGenerator.generate(BeanGenerator.java:35)
> at org.apache.cxf.tools.java2wsdl.processor.JavaToWSDLProcessor.generate(JavaToWSDLProcessor.java:156)
> at org.apache.cxf.tools.java2wsdl.processor.JavaToWSDLProcessor.process(JavaToWSDLProcessor.java:118)
> at org.apache.cxf.tools.java2ws.JavaToWSContainer.processWSDL(JavaToWSContainer.java:110)
> at org.apache.cxf.tools.java2ws.JavaToWSContainer.execute(JavaToWSContainer.java:75)
> at org.apache.cxf.tools.common.toolspec.ToolRunner.runTool(ToolRunner.java:105)
> at org.apache.cxf.tools.common.toolspec.ToolRunner.runTool(ToolRunner.java:45)
> at org.apache.cxf.tools.java2ws.JavaToWS.run(JavaToWS.java:83)
> at org.jboss.wsf.stack.cxf.tools.CXFProviderImpl.provide(CXFProviderImpl.java:200)
> at org.jboss.wsf.stack.cxf.tools.CXFProviderImpl.provide(CXFProviderImpl.java:109)
> at org.jboss.ws.tools.cmd.WSProvide.generate(WSProvide.java:223)
> at org.jboss.ws.tools.cmd.WSProvide.main(WSProvide.java:89)
> at org.jboss.modules.Module.runMainMethod(Module.java:348)
> at org.jboss.modules.Module.run(Module.java:328)
> at org.jboss.modules.Main.main(Main.java:557)
> {noformat}
> *Expected results:*
> No errors
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (WFLY-8954) Wildfly 10 with eclipselink Onscucess observer gets stale entity
by Nuno Godinho de Matos (JIRA)
[ https://issues.jboss.org/browse/WFLY-8954?page=com.atlassian.jira.plugin.... ]
Nuno Godinho de Matos edited comment on WFLY-8954 at 3/1/18 3:42 AM:
---------------------------------------------------------------------
Hi Tomas,
I am very sorry that I have been able to do what you've asked.
Currently I do not have the time availability to check this unfortunately.
I will have to do it in one of my weekends.
Right now the 10.1.0.Final version is working quite well with eclipselink with the fix we have set in, so I cannot prioritize doing this.
Kindest regards.
was (Author: nuno.godinhomatos):
Hi Tomas,
I am very sorry that I have been able to do what you've asked.
Currently I do not have the time availability to check this unfortunately.
I will have to do it in one of my weekends.
Right now the 10.1.0.Final version is working quite well with eclipselink with the fix we have set in, so this does not have priority.
Kindest regards.
> Wildfly 10 with eclipselink Onscucess observer gets stale entity
> ----------------------------------------------------------------
>
> Key: WFLY-8954
> URL: https://issues.jboss.org/browse/WFLY-8954
> Project: WildFly
> Issue Type: Bug
> Components: JPA / Hibernate
> Affects Versions: 10.0.0.Final
> Reporter: Nuno Godinho de Matos
> Assignee: Scott Marlow
> Fix For: 13.0.0.Beta1
>
>
> Hi,
> In widlfly there seems to be an important issue concerning CDI events and observing these events during onsuccess. At least while using eclipselink.
> When using wildfly 10.0.0.Final together with eclipselink, if an application modifies an entity A, fires an event stating entity A has been modified, and an observer consumes this event during transaction success.
> Then the observer will be working with stale entities that do not reflect the modifications done to the entity.
> A sample application for this issue is available in:
> https://github.com/99sono/wildfly10-observe-on-success-stale-entity
> The widlfly configuration xml for the sample application, is available in the application itself, as can be seen in the readme documentation.
> Many thanks for taking a look.
> Kindest regards.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (WFLY-8954) Wildfly 10 with eclipselink Onscucess observer gets stale entity
by Nuno Godinho de Matos (JIRA)
[ https://issues.jboss.org/browse/WFLY-8954?page=com.atlassian.jira.plugin.... ]
Nuno Godinho de Matos edited comment on WFLY-8954 at 3/1/18 3:41 AM:
---------------------------------------------------------------------
Hi Tomas,
I am very sorry that I have been able to do what you've asked.
Currently I do not have the time availability to check this unfortunately.
I will have to do it in one of my weekends.
Right now the 10.1.0.Final version is working quite well with eclipselink with the fix we have set in, so this does not have priority.
Kindest regards.
was (Author: nuno.godinhomatos):
Hi Tomas,
I am very sorry that I have been able to do what you've asked.
Currently I do not have the time availability to check this unfortunatly.
I will have to do it in one of my weekends.
Right now the 10.1.0.Final version is working quite well with eclipselink with the fix we have set in, so this does not have priority.
Kindest regards.
> Wildfly 10 with eclipselink Onscucess observer gets stale entity
> ----------------------------------------------------------------
>
> Key: WFLY-8954
> URL: https://issues.jboss.org/browse/WFLY-8954
> Project: WildFly
> Issue Type: Bug
> Components: JPA / Hibernate
> Affects Versions: 10.0.0.Final
> Reporter: Nuno Godinho de Matos
> Assignee: Scott Marlow
> Fix For: 13.0.0.Beta1
>
>
> Hi,
> In widlfly there seems to be an important issue concerning CDI events and observing these events during onsuccess. At least while using eclipselink.
> When using wildfly 10.0.0.Final together with eclipselink, if an application modifies an entity A, fires an event stating entity A has been modified, and an observer consumes this event during transaction success.
> Then the observer will be working with stale entities that do not reflect the modifications done to the entity.
> A sample application for this issue is available in:
> https://github.com/99sono/wildfly10-observe-on-success-stale-entity
> The widlfly configuration xml for the sample application, is available in the application itself, as can be seen in the readme documentation.
> Many thanks for taking a look.
> Kindest regards.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months