[JBoss JIRA] (DROOLS-1448) [XLS Decision Table] Integer values for Double attributes causes validation error
by Ramya m (Jira)
[ https://issues.jboss.org/browse/DROOLS-1448?page=com.atlassian.jira.plugi... ]
Ramya m commented on DROOLS-1448:
---------------------------------
We are migrating from 6.3.0.Final to 6.5.0.Final. While migrating we too faced the same issue in version 6.5.0.Final. Our SetValue method is compatible for any Object/Primitive data types as the data is dynamic.
Below is our application log.
{color:red}Rule Compilation error The method setValue(Object, Object) in the type RuleFact is not applicable for the arguments (String, int)]{color}
Please let me know is there any patch or any stable version to avoid this issues. Any Migration document from 6.3.0.Final to 7.X is also useful
> [XLS Decision Table] Integer values for Double attributes causes validation error
> ---------------------------------------------------------------------------------
>
> Key: DROOLS-1448
> URL: https://issues.jboss.org/browse/DROOLS-1448
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 7.0.0.Beta6
> Reporter: Jozef Marko
> Assignee: Mario Fusco
> Priority: Minor
> Labels: dtable_testday_preparation, qe-test-day, reported-by-qe
> Attachments: Driver.java, ExamplePolicyPricing.xls, Policy.java, Screenshot from 2017-02-02 10-22-21.png
>
>
> If the XLS decision contains Integer values for column ( attribute ) that is Double data type, then the XLS decision table is not validated successfully. After conversion to guided decision table is the table validated successfully.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 9 months
[JBoss JIRA] (WFLY-11118) inter-app can't be deployed
by Sande Gilda (Jira)
[ https://issues.jboss.org/browse/WFLY-11118?page=com.atlassian.jira.plugin... ]
Sande Gilda commented on WFLY-11118:
------------------------------------
I just tried this with the WildFly quickstart from Git against the wildfly-15.0.0.Alpha1-SNAPSHOT build and get the same failure. Something has changed in the deployment process so that this no longer works.
> inter-app can't be deployed
> ---------------------------
>
> Key: WFLY-11118
> URL: https://issues.jboss.org/browse/WFLY-11118
> Project: WildFly
> Issue Type: Bug
> Components: Quickstarts
> Reporter: Jean-Francois Denise
> Assignee: Eduardo Martins
> Priority: Major
>
> When deploying we have un-resolved dependency.
> I am using jboss EAP quickstarts and wildfly 15.0.0.Alpha1-SNAPSHOT
> 16:45:57,040 INFO [org.jboss.weld.Version] (MSC service thread 1-5) WELD-000900: 3.0.5 (Final)
> 16:45:57,454 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 1) WFLYCTL0013: Operation ("add") failed - address: ([("deployment" => "inter-app-appA.war")]) - failure description: {
> "WFLYCTL0412: Required services that are not installed:" => ["jboss.naming.context.java.global.inter-app-appB.\"BarImpl!org.jboss.as.quickstarts.interapp.shared.Bar\""],
> "WFLYCTL0180: Services with missing/unavailable dependencies" => ["jboss.naming.context.java.module.inter-app-appA.inter-app-appA.env.\"org.jboss.as.quickstarts.interapp.appA.Imports\".bar is missing [jboss.naming.context.java.global.inter-app-appB.\"BarImpl!org.jboss.as.quickstarts.interapp.shared.Bar\"]"]
> }
> 16:45:57,457 ERROR [org.jboss.as.server] (management-handler-thread - 1) WFLYSRV0021: Deploy of deployment "inter-app-appA.war" was rolled back with the following failure message:
> {
> "WFLYCTL0412: Required services that are not installed:" => ["jboss.naming.context.java.global.inter-app-appB.\"BarImpl!org.jboss.as.quickstarts.interapp.shared.Bar\""],
> "WFLYCTL0180: Services with missing/unavailable dependencies" => ["jboss.naming.context.java.module.inter-app-appA.inter-app-appA.env.\"org.jboss.as.quickstarts.interapp.appA.Imports\".bar is missing [jboss.naming.context.java.global.inter-app-appB.\"BarImpl!org.jboss.as.quickstarts.interapp.shared.Bar\"]"]
> }
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 9 months
[JBoss JIRA] (WFLY-10884) Quickstart jaxrs-jwt should use the "jboss.server.config.dir" system property for the file path to jwt.keystore
by Sande Gilda (Jira)
[ https://issues.jboss.org/browse/WFLY-10884?page=com.atlassian.jira.plugin... ]
Sande Gilda commented on WFLY-10884:
------------------------------------
[~emmartins]:
I submitted a fix to the README file, but closed it because it appears a fix was submitted [1] to handle the path issue.
If the existing PR does not look good, you can reopen my PR [2] that fixes it in the README instructions.
[1] https://github.com/wildfly/quickstart/pull/293
[2] https://github.com/wildfly/quickstart/pull/306
> Quickstart jaxrs-jwt should use the "jboss.server.config.dir" system property for the file path to jwt.keystore
> ---------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-10884
> URL: https://issues.jboss.org/browse/WFLY-10884
> Project: WildFly
> Issue Type: Bug
> Components: Quickstarts
> Affects Versions: 13.0.0.Final
> Reporter: Masafumi Miura
> Assignee: Eduardo Martins
> Priority: Major
>
> Quickstart jaxrs-jwt should use the "jboss.server.config.dir" system property for the file path to jwt.keystore.
> We can not expect ../standalone/configuration/jwt.keystore is always a valid path for jwt.keystore because the process current directory can be changed to any other location than $JBOSS_HOME/bin when standalone.sh is invoked from other location.
> For example, when you start WildFly by executing ./bin/standalone.sh under $JBOSS_HOME directory, the request fails with the following FileNotFoundException:
> {code}
> 19:15:57,579 ERROR [stderr] (default task-1) java.io.FileNotFoundException: ../standalone/configuration/jwt.keystore (No such file or directory)
> 19:15:57,581 ERROR [stderr] (default task-1) at java.io.FileInputStream.open0(Native Method)
> 19:15:57,581 ERROR [stderr] (default task-1) at java.io.FileInputStream.open(FileInputStream.java:195)
> 19:15:57,581 ERROR [stderr] (default task-1) at java.io.FileInputStream.<init>(FileInputStream.java:138)
> 19:15:57,582 ERROR [stderr] (default task-1) at java.io.FileInputStream.<init>(FileInputStream.java:93)
> 19:15:57,582 ERROR [stderr] (default task-1) at org.jboss.quickstarts.jaxrsjwt.auth.JwtManager.<clinit>(JwtManager.java:46)
> 19:15:57,583 ERROR [stderr] (default task-1) at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> 19:15:57,583 ERROR [stderr] (default task-1) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> 19:15:57,583 ERROR [stderr] (default task-1) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> 19:15:57,584 ERROR [stderr] (default task-1) at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
> 19:15:57,584 ERROR [stderr] (default task-1) at java.lang.Class.newInstance(Class.java:442)
> 19:15:57,585 ERROR [stderr] (default task-1) at org.jboss.weld.bean.proxy.DefaultProxyInstantiator.newInstance(DefaultProxyInstantiator.java:43)
> 19:15:57,586 ERROR [stderr] (default task-1) at org.jboss.weld.bean.proxy.ProxyFactory.run(ProxyFactory.java:359)
> 19:15:57,586 ERROR [stderr] (default task-1) at org.jboss.weld.bean.proxy.ProxyFactory.create(ProxyFactory.java:343)
> 19:15:57,586 ERROR [stderr] (default task-1) at org.jboss.weld.bean.proxy.ClientProxyFactory.create(ClientProxyFactory.java:81)
> 19:15:57,587 ERROR [stderr] (default task-1) at org.jboss.weld.bean.proxy.ClientProxyProvider.createClientProxy(ClientProxyProvider.java:206)
> ....
> {code}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 9 months
[JBoss JIRA] (WFLY-10529) ParseAndMarshalModelsTestCase fails on the latest IBM8 with Failed to register MBean with MBeanServer
by James Perkins (Jira)
[ https://issues.jboss.org/browse/WFLY-10529?page=com.atlassian.jira.plugin... ]
James Perkins resolved WFLY-10529.
----------------------------------
Fix Version/s: 15.0.0.Alpha1
Resolution: Done
This was fixed by WFLY-11124
> ParseAndMarshalModelsTestCase fails on the latest IBM8 with Failed to register MBean with MBeanServer
> -----------------------------------------------------------------------------------------------------
>
> Key: WFLY-10529
> URL: https://issues.jboss.org/browse/WFLY-10529
> Project: WildFly
> Issue Type: Bug
> Components: Test Suite
> Reporter: Petr Kremensky
> Assignee: James Perkins
> Priority: Major
> Fix For: 15.0.0.Alpha1
>
>
> org.jboss.as.test.manualmode.parse.ParseAndMarshalModelsTestCase from manualmode module of wildlfy testsuite fails with the latest IBM 8 JDK bits.
> *reproduce*
> {noformat}
> wildfly/testsuite]$ mvn test -DtestLogToFile=false -pl integration/manualmode -Dts.manualmode -Dtest=ParseAndMarshalModelsTestCase
> ...
> [ERROR] Tests run: 40, Failures: 40, Errors: 0, Skipped: 0
> {noformat}
> *Error message appearing in the logs*
> {noformat}
> Jun 07, 2018 3:57:14 PM org.jboss.msc.service.ServiceContainerImpl <init>
> ERROR: MSC000010: Failed to register MBean with MBeanServer
> javax.management.InstanceAlreadyExistsException: jboss.msc:type=container,name=host-controller
> at com.sun.jmx.mbeanserver.Repository.addMBean(Repository.java:449)
> at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerWithRepository(DefaultMBeanServerInterceptor.java:1910)
> at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerDynamicMBean(DefaultMBeanServerInterceptor.java:978)
> at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerObject(DefaultMBeanServerInterceptor.java:912)
> at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerMBean(DefaultMBeanServerInterceptor.java:336)
> at com.sun.jmx.mbeanserver.JmxMBeanServer.registerMBean(JmxMBeanServer.java:534)
> at org.jboss.msc.service.ServiceContainerImpl.<init>(ServiceContainerImpl.java:368)
> at org.jboss.msc.service.ServiceContainer$Factory.create(ServiceContainer.java:221)
> at org.wildfly.core.embedded.EmbeddedHostControllerBootstrap$ShutdownHook.register(EmbeddedHostControllerBootstrap.java:90)
> at org.wildfly.core.embedded.EmbeddedHostControllerBootstrap$ShutdownHook.access$100(EmbeddedHostControllerBootstrap.java:80)
> at org.wildfly.core.embedded.EmbeddedHostControllerBootstrap.<init>(EmbeddedHostControllerBootstrap.java:54)
> at org.wildfly.core.embedded.EmbeddedHostControllerFactory$HostControllerImpl.start(EmbeddedHostControllerFactory.java:270)
> at sun.reflect.GeneratedMethodAccessor8.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55)
> at java.lang.reflect.Method.invoke(Method.java:508)
> at org.wildfly.core.embedded.EmbeddedManagedProcessImpl.invokeOnServer(EmbeddedManagedProcessImpl.java:88)
> at org.wildfly.core.embedded.EmbeddedManagedProcessImpl.start(EmbeddedManagedProcessImpl.java:58)
> at org.jboss.as.cli.embedded.EmbedHostControllerHandler.doHandle(EmbedHostControllerHandler.java:268)
> at org.jboss.as.cli.handlers.CommandHandlerWithHelp.handle(CommandHandlerWithHelp.java:89)
> at org.jboss.as.cli.impl.CommandExecutor$2.lambda$build$0(CommandExecutor.java:685)
> at org.jboss.as.cli.impl.CommandExecutor$2$$Lambda$79.00000000200064E0.execute(Unknown Source)
> at org.jboss.as.cli.impl.CommandExecutor.lambda$execute$0(CommandExecutor.java:708)
> at org.jboss.as.cli.impl.CommandExecutor$$Lambda$78.00000000AD3CF710.call(Unknown Source)
> at java.util.concurrent.FutureTask.run(FutureTask.java:277)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1160)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
> at java.lang.Thread.run(Thread.java:811)
> {noformat}
> *Failure cause*
> {noformat}
> Caused by: org.jboss.as.cli.CommandLineException: Cannot start embedded server
> at org.jboss.as.cli.embedded.EmbedServerHandler.doHandle(EmbedServerHandler.java:300)
> at org.jboss.as.cli.handlers.CommandHandlerWithHelp.handle(CommandHandlerWithHelp.java:89)
> at org.jboss.as.cli.impl.CommandExecutor$2.lambda$build$0(CommandExecutor.java:685)
> at org.jboss.as.cli.impl.CommandExecutor$2$$Lambda$79.00000000200064E0.execute(Unknown Source)
> at org.jboss.as.cli.impl.CommandExecutor.lambda$execute$0(CommandExecutor.java:708)
> at org.jboss.as.cli.impl.CommandExecutor$$Lambda$78.00000000AD3CF710.call(Unknown Source)
> at java.util.concurrent.FutureTask.run(FutureTask.java:277)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1160)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
> at java.lang.Thread.run(Thread.java:811)
> Caused by: java.lang.ClassCastException: org.jboss.as.controller.client.helpers.DelegatingModelControllerClient incompatible with org.jboss.as.controller.client.ModelControllerClient
> at org.wildfly.core.embedded.EmbeddedManagedProcessImpl.getModelControllerClient(EmbeddedManagedProcessImpl.java:72)
> at org.jboss.as.cli.embedded.EmbedServerHandler.doHandle(EmbedServerHandler.java:244)
> ... 9 more
> {noformat}
> *Environment*
> {noformat}
> $ mvn -version
> Apache Maven 3.5.3 (3383c37e1f9e9b3bc3df5050c29c8aff9f295297; 2018-02-24T19:49:05Z)
> Maven home: /qa/tools/opt/maven3-latest
> Java version: 1.8.0_171, vendor: IBM Corporation
> Java home: /qa/tools/opt/x86_64/ibm-java-x86_64-sdk-8.0-5.15/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux", version: "3.10.0-862.el7.x86_64", arch: "amd64", family: "unix"
> ---
> $ java -version
> java version "1.8.0_171"
> Java(TM) SE Runtime Environment (build 8.0.5.15 - pxa6480sr5fp15-20180502_01(SR5 FP15))
> IBM J9 VM (build 2.9, JRE 1.8.0 Linux amd64-64 Compressed References 20180425_385365 (JIT enabled, AOT enabled)
> OpenJ9 - a7ffbfe
> OMR - a531219
> IBM - 59ef3dc)
> JCL - 20180425_01 based on Oracle jdk8u171-b11
> {noformat}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 9 months
[JBoss JIRA] (WFLY-11171) Test in Elytron integration tests rely on the BatchPermission in wildfly-jberet
by James Perkins (Jira)
James Perkins created WFLY-11171:
------------------------------------
Summary: Test in Elytron integration tests rely on the BatchPermission in wildfly-jberet
Key: WFLY-11171
URL: https://issues.jboss.org/browse/WFLY-11171
Project: WildFly
Issue Type: Bug
Components: Batch, Test Suite
Reporter: James Perkins
Assignee: Cheng Fang
Tests in the Elytron integration test suite rely on {{org.wildfly.extension.batch.jberet.deployment.BatchPermission}} which is in private module. This permission should likely be moved to a public JBeret API or a new public API should be create within WildFly that exposes this permission. There is a chance this permission may be required for users.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 9 months
[JBoss JIRA] (WFLY-11170) Several basic integration tests use the implementation details from the wildfly-connector extensions
by James Perkins (Jira)
James Perkins created WFLY-11170:
------------------------------------
Summary: Several basic integration tests use the implementation details from the wildfly-connector extensions
Key: WFLY-11170
URL: https://issues.jboss.org/browse/WFLY-11170
Project: WildFly
Issue Type: Bug
Components: JCA, Test Suite
Reporter: James Perkins
Assignee: Stefano Maestri
There are several {{integration/basic}} tests that use objects from the connector extension. These tests should be refactor to use public API's and not rely on implementation details if possible.
The following tests seem to use objects from the {{org.wildfly:wildfly-connector}} dependency. If these can be fixed the {{org.wildfly:wildfly-connector}} dependency should be removed from the basic integration test pom.
* {{AbstractDatasourceCapacityPoliciesTestCase.java}}
* {{AbstractModuleDeploymentTestCase.java}}
* {{AbstractModuleDeploymentTestCaseSetup.java}}
* {{ActivationNameTestCase.java}}
* {{ArchiveValidationDeploymentTestCase.java}}
* {{BasicDeployment10TestCase.java}}
* {{BasicDeployment15TestCase.java}}
* {{BasicDeployment16TestCase.java}}
* {{BasicDeployment17TestCase.java}}
* {{BasicDoubleDeployment16TestCase.java}}
* {{BasicDoubleDeploymentFail16_1TestCase.java}}
* {{BasicDoubleDeploymentFail16_2TestCase.java}}
* {{CustomBootstrapContextTestCase.java}}
* {{DataSourceJdbcStatisticsTestCase.java}}
* {{DatasourceMaxPoolAttributeTestCase.java}}
* {{DatasourceMinPoolAttributeTestCase.java}}
* {{DatasourceNonCcmTestCase.java}}
* {{DatasourcePoolAttributesTestCase.java}}
* {{DatasourceSetTxQueryTimeoutTestCase.java}}
* {{InflowFlatTestCase.java}}
* {{InflowJarTestCase.java}}
* {{IronJacamarDeploymentTestCase.java}}
* {{IronJacamarDoubleDeploymentTestCase.java}}
* {{JCAMetrictsTestBase.java}}
* {{JcaTestsUtil.java}}
* {{LongRunningThreadsCheckTestCase.java}}
* {{MultipleResourceAdapter2.java}}
* {{MultipleResourceAdapter3.java}}
* {{NegativeValidationASTestCase.java}}
* {{NoRaAnnoTestCase.java}}
* {{PositiveValidationTestCase.java}}
* {{RaAnnoTestCase.java}}
* {{RaCfgMetricUnitTestCase.java}}
* {{ResourceAdapterCapacityPoliciesTestCase.java}}
* {{ResourceAdapterPoolAttributesTestCase.java}}
* {{WorkManagerThreadsCheckTestCase.java}}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 9 months
[JBoss JIRA] (WFLY-11166) Create capabilities for TransactionManager, UserTransaction and TransactionSynchronizationRegistry
by David Lloyd (Jira)
[ https://issues.jboss.org/browse/WFLY-11166?page=com.atlassian.jira.plugin... ]
David Lloyd commented on WFLY-11166:
------------------------------------
Even this one subtask might be a bit more complex than it appears. The three types mentioned in the summary are _always_ available, thanks to the transaction client library. The real capability from the perspective of the usage of these three types is the local transaction provider, which would normally come from the org.jboss.as.transaction extension.
And yet, if no subsystem provides the capability, the system may still be usable. The transaction client library will still function, though certain transaction-related operations will obviously be disallowed. Additionally, it's not impossible that at some point in the future we may support more than one local transaction provider at once, with an application- or component-specific manner of selecting the provider to use.
> Create capabilities for TransactionManager, UserTransaction and TransactionSynchronizationRegistry
> --------------------------------------------------------------------------------------------------
>
> Key: WFLY-11166
> URL: https://issues.jboss.org/browse/WFLY-11166
> Project: WildFly
> Issue Type: Sub-task
> Components: Management, Transactions
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
> Priority: Major
>
> See https://issues.jboss.org/browse/WFLY-9587?focusedCommentId=13647549&page=... in the parent issue.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 9 months