[JBoss JIRA] (DROOLS-4731) Working with Long field
by Pavel Tavoda (Jira)
[ https://issues.jboss.org/browse/DROOLS-4731?page=com.atlassian.jira.plugi... ]
Pavel Tavoda updated DROOLS-4731:
---------------------------------
Attachment: error-with-long.zip
> Working with Long field
> -----------------------
>
> Key: DROOLS-4731
> URL: https://issues.jboss.org/browse/DROOLS-4731
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 7.28.0.Final
> Reporter: Pavel Tavoda
> Assignee: Mario Fusco
> Priority: Major
> Attachments: error-with-long.zip
>
>
> Setting long field value in THEN:
> This are two problems:
> 1) package as kjar 'mvn clean install' result in "Error: unable to resolve method using strict-mode: org.drools.core.spi.Activation.setValue(java.lang.Integer)"
> RESULT:
> IntInRuleJava.drl - FAIL
> IntInRuleMvel.drl - FAIL
> LongInRuleJava.drl - OK
> LongInRuleMvel.drl - FAIL
> LongError.gdst - FAIL
> 2) with 'mvn clean install -DgenerateModel=YES' it result in 'incompatible types: int cannot be converted to java.lang.Long'
> IntInRuleJava.drl - FAIL
> IntInRuleMvel.drl - FAIL
> LongInRuleJava.drl - OK
> LongInRuleMvel.drl - OK
> LongError.gdst - FAIL
> I don't know how to turn off strict mode for maven plugin. Setting 'drools.dialect.mvel.strict' in kmodule.xml doesn't work.
> Example project attached.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 6 months
[JBoss JIRA] (DROOLS-4731) Working with Long field
by Pavel Tavoda (Jira)
Pavel Tavoda created DROOLS-4731:
------------------------------------
Summary: Working with Long field
Key: DROOLS-4731
URL: https://issues.jboss.org/browse/DROOLS-4731
Project: Drools
Issue Type: Bug
Components: core engine
Affects Versions: 7.28.0.Final
Reporter: Pavel Tavoda
Assignee: Mario Fusco
Setting long field value in THEN:
This are two problems:
1) package as kjar 'mvn clean install' result in "Error: unable to resolve method using strict-mode: org.drools.core.spi.Activation.setValue(java.lang.Integer)"
RESULT:
IntInRuleJava.drl - FAIL
IntInRuleMvel.drl - FAIL
LongInRuleJava.drl - OK
LongInRuleMvel.drl - FAIL
LongError.gdst - FAIL
2) with 'mvn clean install -DgenerateModel=YES' it result in 'incompatible types: int cannot be converted to java.lang.Long'
IntInRuleJava.drl - FAIL
IntInRuleMvel.drl - FAIL
LongInRuleJava.drl - OK
LongInRuleMvel.drl - OK
LongError.gdst - FAIL
I don't know how to turn off strict mode for maven plugin. Setting 'drools.dialect.mvel.strict' in kmodule.xml doesn't work.
Example project attached.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 6 months
[JBoss JIRA] (WFLY-12135) Error deploying web service without http-listener (only https-listener)
by Ingo Weiss (Jira)
[ https://issues.jboss.org/browse/WFLY-12135?page=com.atlassian.jira.plugin... ]
Ingo Weiss commented on WFLY-12135:
-----------------------------------
Part of the problem is rewriting the WSDL to reflect the correct protocol. The solution I came up with was attaching a boolean to the deployment unit to be verified by JBossWS and then rewrite the WSDL address accordingly.
> Error deploying web service without http-listener (only https-listener)
> ------------------------------------------------------------------------
>
> Key: WFLY-12135
> URL: https://issues.jboss.org/browse/WFLY-12135
> Project: WildFly
> Issue Type: Bug
> Components: Web Services
> Affects Versions: 17.0.0.Beta1
> Reporter: Radoslav Husar
> Assignee: Ingo Weiss
> Priority: Major
>
> Deploying a application with only a https-listener (default http-listener was removed) gives error:
> Caused by: java.lang.IllegalStateException: WFLYUT0063: Could not find the port number listening for protocol HTTP/1.1
> at org.wildfly.extension.undertow.WebServerService.getPort(WebServerService.java:68)
> at org.jboss.as.webservices.config.WebServerInfoImpl.getPort(WebServerInfoImpl.java:36)
> at org.jboss.ws.common.management.AbstractServerConfig.getConnectorPort(AbstractServerConfig.java:328)
> at org.jboss.ws.common.management.AbstractServerConfig.getWebServicePort(AbstractServerConfig.java:237)
> at org.jboss.wsf.spi.metadata.config.SOAPAddressRewriteMetadata.getWebServicePort(SOAPAddressRewriteMetadata.java:66)
> at org.jboss.ws.common.deployment.EndpointAddressDeploymentAspect$PortValue.getPortValue(EndpointAddressDeploymentAspect.java:224)
> at org.jboss.ws.common.deployment.EndpointAddressDeploymentAspect$PortValue.getValue(EndpointAddressDeploymentAspect.java:217)
> at org.jboss.ws.common.deployment.EndpointAddressDeploymentAspect.start(EndpointAddressDeploymentAspect.java:84)
> at org.jboss.as.webservices.deployers.AspectDeploymentProcessor.deploy(AspectDeploymentProcessor.java:73)
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:165)
> ... 5 more
> A workaround is to use webservices configuration to define modify-wsdl-address and wsdl-port (for wsdl soap address rewriting) or jboss-webservices.xml to define wsdl.soapAddress.rewrite.wsdl-port.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 6 months
[JBoss JIRA] (WFLY-12135) Error deploying web service without http-listener (only https-listener)
by Ingo Weiss (Jira)
[ https://issues.jboss.org/browse/WFLY-12135?page=com.atlassian.jira.plugin... ]
Ingo Weiss reassigned WFLY-12135:
---------------------------------
Assignee: Ingo Weiss (was: Jim Ma)
> Error deploying web service without http-listener (only https-listener)
> ------------------------------------------------------------------------
>
> Key: WFLY-12135
> URL: https://issues.jboss.org/browse/WFLY-12135
> Project: WildFly
> Issue Type: Bug
> Components: Web Services
> Affects Versions: 17.0.0.Beta1
> Reporter: Radoslav Husar
> Assignee: Ingo Weiss
> Priority: Major
>
> Deploying a application with only a https-listener (default http-listener was removed) gives error:
> Caused by: java.lang.IllegalStateException: WFLYUT0063: Could not find the port number listening for protocol HTTP/1.1
> at org.wildfly.extension.undertow.WebServerService.getPort(WebServerService.java:68)
> at org.jboss.as.webservices.config.WebServerInfoImpl.getPort(WebServerInfoImpl.java:36)
> at org.jboss.ws.common.management.AbstractServerConfig.getConnectorPort(AbstractServerConfig.java:328)
> at org.jboss.ws.common.management.AbstractServerConfig.getWebServicePort(AbstractServerConfig.java:237)
> at org.jboss.wsf.spi.metadata.config.SOAPAddressRewriteMetadata.getWebServicePort(SOAPAddressRewriteMetadata.java:66)
> at org.jboss.ws.common.deployment.EndpointAddressDeploymentAspect$PortValue.getPortValue(EndpointAddressDeploymentAspect.java:224)
> at org.jboss.ws.common.deployment.EndpointAddressDeploymentAspect$PortValue.getValue(EndpointAddressDeploymentAspect.java:217)
> at org.jboss.ws.common.deployment.EndpointAddressDeploymentAspect.start(EndpointAddressDeploymentAspect.java:84)
> at org.jboss.as.webservices.deployers.AspectDeploymentProcessor.deploy(AspectDeploymentProcessor.java:73)
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:165)
> ... 5 more
> A workaround is to use webservices configuration to define modify-wsdl-address and wsdl-port (for wsdl soap address rewriting) or jboss-webservices.xml to define wsdl.soapAddress.rewrite.wsdl-port.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 6 months
[JBoss JIRA] (WFCORE-3739) [IBM JDK] Unable to start server with FIPS Bouncy Castle
by Martin Choma (Jira)
[ https://issues.jboss.org/browse/WFCORE-3739?page=com.atlassian.jira.plugi... ]
Martin Choma commented on WFCORE-3739:
--------------------------------------
This issue is now about the hardcoded `SHA-1`. Isn't there more portable algorithm, which will be present in all jdks configuration? Or shouldnt it be parametrized? Or shouldnt it be written in discovery way: Try SHA-1 if not available try something else ...
Parametrization seems most robust
> [IBM JDK] Unable to start server with FIPS Bouncy Castle
> --------------------------------------------------------
>
> Key: WFCORE-3739
> URL: https://issues.jboss.org/browse/WFCORE-3739
> Project: WildFly Core
> Issue Type: Bug
> Components: Security
> Affects Versions: 5.0.0.Alpha2
> Environment: java -version
> java version "1.8.0_161"
> Java(TM) SE Runtime Environment (build 8.0.5.10 - pxa6480sr5fp10-20180214_01(SR5 FP10))
> IBM J9 VM (build 2.9, JRE 1.8.0 Linux amd64-64 Compressed References 20180208_378436 (JIT enabled, AOT enabled)
> OpenJ9 - 39bb844
> OMR - c04ccb2
> IBM - 2321a81)
> JCL - 20180209_01 based on Oracle jdk8u161-b12
> Reporter: Martin Choma
> Priority: Major
>
> {code}
> 18:09:45,494 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-2) MSC000001: Failed to start service jboss.as: org.jboss.msc.service.StartException in service jboss.as: Failed to start service
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.execute(ServiceControllerImpl.java:1706)
> at org.jboss.msc.service.ServiceControllerImpl$ControllerTask.run(ServiceControllerImpl.java:1540)
> at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
> at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1985)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1487)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1378)
> at java.lang.Thread.run(Thread.java:811)
> Caused by: java.lang.IllegalStateException: WFLYDR0005: Cannot obtain SHA-1 MessageDigest
> at org.jboss.as.repository.ContentRepositoryImpl.<init>(ContentRepositoryImpl.java:92)
> at org.jboss.as.repository.ContentRepository$Factory.addService(ContentRepository.java:185)
> at org.jboss.as.server.ApplicationServerService.start(ApplicationServerService.java:145)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1714)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.execute(ServiceControllerImpl.java:1693)
> ... 6 more
> Caused by: java.security.NoSuchAlgorithmException: SHA-1 MessageDigest not available
> at sun.security.jca.GetInstance.getInstance(GetInstance.java:171)
> at java.security.Security.getImpl(Security.java:706)
> at java.security.MessageDigest.getInstance(MessageDigest.java:178)
> at org.jboss.as.repository.ContentRepositoryImpl.<init>(ContentRepositoryImpl.java:90)
> ... 10 more
> {code}
> SHA-1 is hardcoded in server, which apparently is not available in FIPS BC.
> {code:java|title=ContentRepositoryImpl.java}
> protected ContentRepositoryImpl(final File repoRoot, final File tmpRoot, long obsolescenceTimeout, long lockTimeout) {
> Assert.checkNotNullParam("repoRoot", repoRoot);
> Assert.checkNotNullParam("tmpRoot", tmpRoot);
> checkDirectory(repoRoot);
> this.repoRoot = repoRoot;
> checkDirectory(tmpRoot);
> this.tmpRoot = tmpRoot;
> this.obsolescenceTimeout = obsolescenceTimeout;
> this.lockTimeout = lockTimeout;
> try {
> this.messageDigest = MessageDigest.getInstance("SHA-1");
> } catch (NoSuchAlgorithmException e) {
> throw DeploymentRepositoryLogger.ROOT_LOGGER.cannotObtainSha1(e, MessageDigest.class.getSimpleName());
> }
> }
> {code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 6 months
[JBoss JIRA] (WFLY-12768) Extract microprofile-metrics galleon layer from observability
by Radoslav Husar (Jira)
Radoslav Husar created WFLY-12768:
-------------------------------------
Summary: Extract microprofile-metrics galleon layer from observability
Key: WFLY-12768
URL: https://issues.jboss.org/browse/WFLY-12768
Project: WildFly
Issue Type: Task
Components: MP Metrics
Reporter: Radoslav Husar
Assignee: Radoslav Husar
Fix For: 19.0.0.Beta1
Similar to WFLY-12759:
{quote}Some microprofile extensions only depend on microprofile-config and not health or metrics. Splitting this into a separate layer will accommodate layers for other microprofile specs.{quote}
The fault tolerance unfortunately requires config and metrics, but not health.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 6 months
[JBoss JIRA] (WFLY-12733) EJB Timers: Forcing refresh timers in a database-data-store in a clustered environment
by Cheng Fang (Jira)
[ https://issues.jboss.org/browse/WFLY-12733?page=com.atlassian.jira.plugin... ]
Cheng Fang commented on WFLY-12733:
-----------------------------------
[~brian.stansberry] If we expose this functionality through managment operation (CLI & admin console), will it be easy to call it and get result from application code? I think the user wanted to do it directly from application code, not from cli shell or admin console, though the latter is also nice to have.
> EJB Timers: Forcing refresh timers in a database-data-store in a clustered environment
> --------------------------------------------------------------------------------------
>
> Key: WFLY-12733
> URL: https://issues.jboss.org/browse/WFLY-12733
> Project: WildFly
> Issue Type: Feature Request
> Components: EJB
> Reporter: Rhuan Rocha
> Assignee: Cheng Fang
> Priority: Major
>
> The EJB Timer has a way to persist timers in a database using datasources. It is described [here|https://docs.jboss.org/author/display/WFLY10/EJB3+Clustered+Database...]. The database-data-store has an attribute called refresh-interval that define a time in milliseconds to refresh the timers reading the timers from database. Look this sample of configuration.
>
> {code:java}
> <data-stores>
> <file-data-store name="default-file-store" path="timer-service-data" relative-to="jboss.server.data.dir"/>
> <database-data-store name="clustered-store" datasource-jndi-name="java:/jdbc/MyDataSource" partition="timer" refresh-interval="60000" allow-execution="true"/>
> </data-stores>
> {code}
> The RFE is to Wildfly provide a way to force the refresh programmatically.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 6 months
[JBoss JIRA] (WFCORE-4291) Restore legacy (not "graceful") startup mode
by Vladimir Grabarchuk (Jira)
[ https://issues.jboss.org/browse/WFCORE-4291?page=com.atlassian.jira.plugi... ]
Vladimir Grabarchuk commented on WFCORE-4291:
---------------------------------------------
Looks like this didn't make it into 18 - can you please confirm? Will it make it into 19?
> Restore legacy (not "graceful") startup mode
> --------------------------------------------
>
> Key: WFCORE-4291
> URL: https://issues.jboss.org/browse/WFCORE-4291
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Management
> Reporter: Vladimir Grabarchuk
> Assignee: Brian Stansberry
> Priority: Major
>
> Please allow a configurable legacy startup mode which was the default before WF11, when components can service HTTP requests as soon as they are deployed, not when the container deploys all components.
> The use case for this is the following: there is a configuration service component upon which other components depend for configuration data, requested and served via a HTTP request. With the new "graceful startup" this scenario no longer seems possible, as it results in read timeouts, mis-configured artifacts, and failed deployments altogether.
> If generally feasible, another value of the *--start-mode=legacy* seems appropriate to accommodate the original (legacy) behavior.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 6 months