[JBoss JIRA] (DROOLS-1545) Fix date and time functions and arithmetic
by Edson Tirelli (JIRA)
Edson Tirelli created DROOLS-1545:
-------------------------------------
Summary: Fix date and time functions and arithmetic
Key: DROOLS-1545
URL: https://issues.jboss.org/browse/DROOLS-1545
Project: Drools
Issue Type: Bug
Components: dmn engine
Affects Versions: 7.0.0.CR3
Reporter: Edson Tirelli
Assignee: Edson Tirelli
Fix For: 7.1.0.Final
This ticket includes two fixes:
1. For the {{date and time( from )}} , where {{from}} is a string, the time part of the string should be optional. E.g.:
{code}
date and time( "2017-05-06" ) = date and time( "2017-05-06T00:00" )
{code}
2. Extend date arithmetics to support subtracting two dates. The result should be the number of days between dates, ignoring daylight shifts and timezones. E.g.:
{code}
date( "2017-05-05" ) - date( "2017-05-01" ) = duration( "P4D" )
{code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years
[JBoss JIRA] (JGRP-2169) PDC.java can NPE when calling deleteFile
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2169?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-2169:
---------------------------
Fix Version/s: 4.0.3
> PDC.java can NPE when calling deleteFile
> ----------------------------------------
>
> Key: JGRP-2169
> URL: https://issues.jboss.org/browse/JGRP-2169
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 4.0.1
> Reporter: Elias Ross
> Assignee: Bela Ban
> Fix For: 4.0.3
>
>
> As seen in my logs:
> {noformat}
> [thread=jgroups-4,pv36d01ls-geo02042101-26405] [level=ERROR] [logger=unknown.jul.logger] - JGRP000027: failed passing message up
> java.lang.NullPointerException: null
> at org.jgroups.protocols.PDC.deleteFile(PDC.java:271) ~[org.jgroups-jgroups-4.0.1.Final.jar:4.0.1.Final]
> at org.jgroups.protocols.PDC.writeNodeToDisk(PDC.java:208) ~[org.jgroups-jgroups-4.0.1.Final.jar:4.0.1.Final]
> at org.jgroups.protocols.PDC.down(PDC.java:89) ~[org.jgroups-jgroups-4.0.1.Final.jar:4.0.1.Final]
> {noformat}
> It seems that there are code paths where deleteFile can be called with a null parameter. For example:
> {code:java}
> protected File writeToTempFile(File dir, Address logical_addr, Address physical_addr, String logical_name) throws Exception {
> DataOutputStream out=null;
> File file=null;
> String filename=null;
> try {
> file=File.createTempFile("temp", null, dir);
> ^^ If this fails, then file is null and delete is called with null
> filename=file.getName();
> ...
> }
> catch(Exception e) {
> Util.close(out);
> log.error(Util.getMessage("FailedToWriteTemporaryFile") + filename, e);
> deleteFile(file);
> return null;
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years
[JBoss JIRA] (WFCORE-1282) Unable to create HTTPS connection using *ECDH_RSA* cipher suites / kECDHr cipher string
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1282?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFCORE-1282:
-------------------------------------
Fix Version/s: 3.0.0.Beta19
(was: 3.0.0.Beta18)
> Unable to create HTTPS connection using *ECDH_RSA* cipher suites / kECDHr cipher string
> ---------------------------------------------------------------------------------------
>
> Key: WFCORE-1282
> URL: https://issues.jboss.org/browse/WFCORE-1282
> Project: WildFly Core
> Issue Type: Bug
> Components: Security
> Affects Versions: 1.0.2.Final
> Environment: Oracle Java
> Reporter: Martin Choma
> Assignee: Darran Lofthouse
> Priority: Critical
> Fix For: 3.0.0.Beta19
>
> Attachments: client_debug_eap6.log, client_debug_eap7.log, server-cert-key-ec.jks, server_debug_eap6.log, server_debug_eap7.log
>
>
> User using these cipher suites / cipher name in EAP6 won't be able to use it in EAP7.
> Setting as critical as these cipher suites, are considered for strong and widely used in my opinion.
> In server log, error "no cipher suites in common" can be seen using -Djavax.net.debug=all.
> Note, that analogous configuration in EAP6 works fine.
> Issue can be seen on Oracle Java only, as on OpenJDK / IBM these suites are not provided by method getDefaultCipherSuites().
> Also is it possible to log "no cipher suites in common" and similar tls handshake errors without -Djavax.net.debug for better troubleshooting?
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years
[JBoss JIRA] (WFCORE-2068) HTTPSConnectionWithCLITestCase and HTTPSManagementInterfaceTestCase Failing Due To Native Protocol Issue
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2068?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFCORE-2068:
-------------------------------------
Fix Version/s: 3.0.0.Beta19
(was: 3.0.0.Beta18)
> HTTPSConnectionWithCLITestCase and HTTPSManagementInterfaceTestCase Failing Due To Native Protocol Issue
> --------------------------------------------------------------------------------------------------------
>
> Key: WFCORE-2068
> URL: https://issues.jboss.org/browse/WFCORE-2068
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management, Remoting, Test Suite
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
> Priority: Blocker
> Fix For: 3.0.0.Beta19
>
>
> The listed test case is failing during clean up with the following error: -
> {noformat}
> java.io.IOException: java.io.IOException: WFLYPRT0054: Channel closed
> at org.jboss.as.protocol.mgmt.ManagementClientChannelStrategy$Establishing.getChannel(ManagementClientChannelStrategy.java:166)
> at org.jboss.as.controller.client.impl.RemotingModelControllerClient.getOrCreateChannel(RemotingModelControllerClient.java:135)
> at org.jboss.as.controller.client.impl.RemotingModelControllerClient$1.getChannel(RemotingModelControllerClient.java:59)
> at org.jboss.as.protocol.mgmt.ManagementChannelHandler.executeRequest(ManagementChannelHandler.java:135)
> at org.jboss.as.protocol.mgmt.ManagementChannelHandler.executeRequest(ManagementChannelHandler.java:110)
> at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeRequest(AbstractModelControllerClient.java:263)
> at org.jboss.as.controller.client.impl.AbstractModelControllerClient.execute(AbstractModelControllerClient.java:168)
> at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeForResult(AbstractModelControllerClient.java:147)
> at org.jboss.as.controller.client.impl.AbstractModelControllerClient.execute(AbstractModelControllerClient.java:80)
> {noformat}
> The stage of the test using HTTP Upgrade over a HTTPS connection appears to be working fine, the issue is with the native management interface used for test clean up.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years