January 2015 - jboss-jira - Jboss List Archives

[JBoss JIRA] (DROOLS-698) GlobalDateExtractor should not use java.sql.Date

by Tibor Foris (JIRA)

[ https://issues.jboss.org/browse/DROOLS-698?page=com.atlassian.jira.plugin... ] Tibor Foris commented on DROOLS-698: ------------------------------------ Thank you. Regards, Tibor > GlobalDateExtractor should not use java.sql.Date > ------------------------------------------------ > > Key: DROOLS-698 > URL: https://issues.jboss.org/browse/DROOLS-698 > Project: Drools > Issue Type: Bug > Affects Versions: 6.1.0.Final > Reporter: Tibor Foris > Assignee: Mario Fusco > Fix For: 6.2.0.Final > > > The GlobalDateExtractor class uses java.sql.Date instead of java.util.Date. > This leads to class cast exceptions (java.sql.Date against java.util.Date) when using globals of type date (java.util.Date). -- This message was sent by Atlassian JIRA (v6.3.11#6341)

10 years, 11 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-672) Drools audit log view cannot be opened

by Mario Fusco (JIRA)

[ https://issues.jboss.org/browse/DROOLS-672?page=com.atlassian.jira.plugin... ] Mario Fusco reassigned DROOLS-672: ---------------------------------- Assignee: Mario Fusco (was: Mark Proctor) > Drools audit log view cannot be opened > -------------------------------------- > > Key: DROOLS-672 > URL: https://issues.jboss.org/browse/DROOLS-672 > Project: Drools > Issue Type: Bug > Affects Versions: 6.0.1.Final > Reporter: Jose Luis Melgar > Assignee: Mario Fusco > Labels: Drools > > On behalf of Gergely Bacso: > {quote} > From: Mark Proctor > Sent: ‎20/‎12/‎2014 21:15 > To: drools-setup(a)googlegroups.com > Cc: Bob Brodt > Subject: Re: [drools-setup] Drools audit log view cannot be opened > please open a JIRA, so we can be sure to fix this. > Thanks > Mark > {quote} > {quote} > On 19 Dec 2014, at 18:19, Gergely Bacsó wrote: > Hi, > First of all: this problem can be reproduced with only a single audit file. > I managed to get closer to the solution by spending a few hours reading Drools source code: > The Eclipse plugin has a class called AuditView, this class expects RuleFlowGroupNode-s in the right sequence, or it blows up: > http://grepcode.com/file/repo1.maven.org/maven2/org.drools/org.drools.ecl... (see line 515, stack.pop()) > Since my audit logs for some reason contain several of > AFTER_RULEFLOW_GROUP_DEACTIVATED entries without having any BEFORE_RULEFLOW_GROUP_DEACTIVATED entries preceding them, the AuditView fails to parse the log.Currently I am manually removing these non-matched entries to be able to open the file, and planning to spend some time on further analysis after the holidays. > Gergely > {quote} -- This message was sent by Atlassian JIRA (v6.3.11#6341)

10 years, 11 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-698) GlobalDateExtractor should not use java.sql.Date

by Mario Fusco (JIRA)

[ https://issues.jboss.org/browse/DROOLS-698?page=com.atlassian.jira.plugin... ] Mario Fusco resolved DROOLS-698. -------------------------------- Fix Version/s: 6.2.0.Final Resolution: Done Fixed by https://github.com/droolsjbpm/drools/commit/9612e92c7 > GlobalDateExtractor should not use java.sql.Date > ------------------------------------------------ > > Key: DROOLS-698 > URL: https://issues.jboss.org/browse/DROOLS-698 > Project: Drools > Issue Type: Bug > Affects Versions: 6.1.0.Final > Reporter: Tibor Foris > Assignee: Mario Fusco > Fix For: 6.2.0.Final > > > The GlobalDateExtractor class uses java.sql.Date instead of java.util.Date. > This leads to class cast exceptions (java.sql.Date against java.util.Date) when using globals of type date (java.util.Date). -- This message was sent by Atlassian JIRA (v6.3.11#6341)

10 years, 11 months

1
0
0 / 0

[JBoss JIRA] (SECURITY-772) SPNEGOLoginModule does not always respect removeRealmFromPrincipal

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/SECURITY-772?page=com.atlassian.jira.plug... ] RH Bugzilla Integration commented on SECURITY-772: -------------------------------------------------- Ondrej Lukas <olukas(a)redhat.com> changed the Status of [bug 1039989|https://bugzilla.redhat.com/show_bug.cgi?id=1039989] from ON_QA to VERIFIED > SPNEGOLoginModule does not always respect removeRealmFromPrincipal > ------------------------------------------------------------------ > > Key: SECURITY-772 > URL: https://issues.jboss.org/browse/SECURITY-772 > Project: PicketBox > Issue Type: Bug > Components: Negotiation > Affects Versions: Negotiation_2_2_6 > Reporter: Tom Fonteyne > Assignee: Tom Fonteyne > Priority: Minor > Fix For: Negotiation_2_2_7 > > > org.jboss.security.negotiation.spnego.SPNEGOLoginModule > private class AcceptSecContext: > if (gssContext.isEstablished()) > { > log.warn("Authentication was performed despite already being authenticated!"); > // TODO - Refactor to only do this once. > setIdentity(new KerberosPrincipal(gssContext.getSrcName().toString())); > The last line should obey the "removeRealmFromPrincipal" flag similarly as a bit further down: > setIdentity(createIdentity(gssContext.getSrcName().toString())); -- This message was sent by Atlassian JIRA (v6.3.11#6341)

10 years, 11 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-698) GlobalDateExtractor should not use java.sql.Date

by Mario Fusco (JIRA)

[ https://issues.jboss.org/browse/DROOLS-698?page=com.atlassian.jira.plugin... ] Mario Fusco reassigned DROOLS-698: ---------------------------------- Assignee: Mario Fusco (was: Mark Proctor) > GlobalDateExtractor should not use java.sql.Date > ------------------------------------------------ > > Key: DROOLS-698 > URL: https://issues.jboss.org/browse/DROOLS-698 > Project: Drools > Issue Type: Bug > Affects Versions: 6.1.0.Final > Reporter: Tibor Foris > Assignee: Mario Fusco > > The GlobalDateExtractor class uses java.sql.Date instead of java.util.Date. > This leads to class cast exceptions (java.sql.Date against java.util.Date) when using globals of type date (java.util.Date). -- This message was sent by Atlassian JIRA (v6.3.11#6341)

10 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ELY-139) ByteStringBuilder.appendUtf8Raw() cannot append lonely surrogates

by Jan Kalina (JIRA)

[ https://issues.jboss.org/browse/ELY-139?page=com.atlassian.jira.plugin.sy... ] Jan Kalina updated ELY-139: --------------------------- Description: ByteStringBuilder cannot append codepoints 0xD8xx (lonely surrogates). It should - StringBuilder.appendCodePoint() work with it. (Problem is only with uncomplete/nonvalid unicode strings, so it is not critical problem.) Mentioned in: https://github.com/wildfly-security/wildfly-elytron/pull/101 *UPDATE:* ByteStringBuilder encode surrogates correctly by RFC3629 (if we ignore they are prohibited because they are reserved for UTF-16). Conversly StringBuilder and {{ (char) }} operator encode D800-D8FF bad as 3F. Problem is only in appending into ByteStringBuilder constructed as: {code:xml} new ByteStringBuilder(new byte[]{}); {code} was: ByteStringBuilder cannot append codepoints 0xD8xx (lonely surrogates). It should - StringBuilder.appendCodePoint() work with it. (Problem is only with uncomplete/nonvalid unicode strings, so it is not critical problem.) Mentioned in: https://github.com/wildfly-security/wildfly-elytron/pull/101 *UPDATE:* ByteStringBuilder encode surrogates correctly by RFC3629 (if we ignore they are prohibited because they are reserved for UTF-16). Conversly StringBuilder and {{(char)}} operator encode D800-D8FF bad as 3F. Problem is only in appending into ByteStringBuilder constructed as: {code:xml} new ByteStringBuilder(new byte[]{}); {/code} > ByteStringBuilder.appendUtf8Raw() cannot append lonely surrogates > ----------------------------------------------------------------- > > Key: ELY-139 > URL: https://issues.jboss.org/browse/ELY-139 > Project: WildFly Elytron > Issue Type: Bug > Reporter: Jan Kalina > Assignee: Jan Kalina > Priority: Minor > > ByteStringBuilder cannot append codepoints 0xD8xx (lonely surrogates). It should - StringBuilder.appendCodePoint() work with it. > (Problem is only with uncomplete/nonvalid unicode strings, so it is not critical problem.) > Mentioned in: https://github.com/wildfly-security/wildfly-elytron/pull/101 > *UPDATE:* > ByteStringBuilder encode surrogates correctly by RFC3629 (if we ignore they are prohibited because they are reserved for UTF-16). Conversly StringBuilder and {{ (char) }} operator encode D800-D8FF bad as 3F. > Problem is only in appending into ByteStringBuilder constructed as: > {code:xml} > new ByteStringBuilder(new byte[]{}); > {code} -- This message was sent by Atlassian JIRA (v6.3.11#6341)

10 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ELY-139) ByteStringBuilder.appendUtf8Raw() cannot append lonely surrogates

by Jan Kalina (JIRA)

[ https://issues.jboss.org/browse/ELY-139?page=com.atlassian.jira.plugin.sy... ] Jan Kalina updated ELY-139: --------------------------- Description: ByteStringBuilder cannot append codepoints 0xD8xx (lonely surrogates). It should - StringBuilder.appendCodePoint() work with it. (Problem is only with uncomplete/nonvalid unicode strings, so it is not critical problem.) Mentioned in: https://github.com/wildfly-security/wildfly-elytron/pull/101 *UPDATE:* ByteStringBuilder encode surrogates correctly by RFC3629 (if we ignore they are prohibited because they are reserved for UTF-16). Conversly StringBuilder and (char) operator encode D800-D8FF bad as 3F. Problem is only in appending into ByteStringBuilder constructed as: {code:xml} new ByteStringBuilder(new byte[]{}); {code} was: ByteStringBuilder cannot append codepoints 0xD8xx (lonely surrogates). It should - StringBuilder.appendCodePoint() work with it. (Problem is only with uncomplete/nonvalid unicode strings, so it is not critical problem.) Mentioned in: https://github.com/wildfly-security/wildfly-elytron/pull/101 *UPDATE:* ByteStringBuilder encode surrogates correctly by RFC3629 (if we ignore they are prohibited because they are reserved for UTF-16). Conversly StringBuilder and {{ (char) }} operator encode D800-D8FF bad as 3F. Problem is only in appending into ByteStringBuilder constructed as: {code:xml} new ByteStringBuilder(new byte[]{}); {code} > ByteStringBuilder.appendUtf8Raw() cannot append lonely surrogates > ----------------------------------------------------------------- > > Key: ELY-139 > URL: https://issues.jboss.org/browse/ELY-139 > Project: WildFly Elytron > Issue Type: Bug > Reporter: Jan Kalina > Assignee: Jan Kalina > Priority: Minor > > ByteStringBuilder cannot append codepoints 0xD8xx (lonely surrogates). It should - StringBuilder.appendCodePoint() work with it. > (Problem is only with uncomplete/nonvalid unicode strings, so it is not critical problem.) > Mentioned in: https://github.com/wildfly-security/wildfly-elytron/pull/101 > *UPDATE:* > ByteStringBuilder encode surrogates correctly by RFC3629 (if we ignore they are prohibited because they are reserved for UTF-16). Conversly StringBuilder and (char) operator encode D800-D8FF bad as 3F. > Problem is only in appending into ByteStringBuilder constructed as: > {code:xml} > new ByteStringBuilder(new byte[]{}); > {code} -- This message was sent by Atlassian JIRA (v6.3.11#6341)

10 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ELY-139) ByteStringBuilder.appendUtf8Raw() cannot append lonely surrogates

by Jan Kalina (JIRA)

[ https://issues.jboss.org/browse/ELY-139?page=com.atlassian.jira.plugin.sy... ] Jan Kalina updated ELY-139: --------------------------- Description: ByteStringBuilder cannot append codepoints 0xD8xx (lonely surrogates). It should - StringBuilder.appendCodePoint() work with it. (Problem is only with uncomplete/nonvalid unicode strings, so it is not critical problem.) Mentioned in: https://github.com/wildfly-security/wildfly-elytron/pull/101 *UPDATE:* ByteStringBuilder encode surrogates correctly by RFC3629 (if we ignore they are prohibited because they are reserved for UTF-16). Conversly StringBuilder and {{(char)}} operator encode D800-D8FF bad as 3F. Problem is only in appending into ByteStringBuilder constructed as: {code:xml} new ByteStringBuilder(new byte[]{}); {/code} was: ByteStringBuilder cannot append codepoints 0xD8xx (lonely surrogates). It should - StringBuilder.appendCodePoint() work with it. (Problem is only with uncomplete/nonvalid unicode strings, so it is not critical problem.) Mentioned in: https://github.com/wildfly-security/wildfly-elytron/pull/101 **UPDATE:** ByteStringBuilder encode surrogates correctly by RFC3629 (if we ignore they are prohibited because they are reserved for UTF-16). Conversly StringBuilder and `(char)` operator encode D800-D8FF bad as 3F. Problem is only in appending into ByteStringBuilder constructed as: new ByteStringBuilder(new byte[]{}); > ByteStringBuilder.appendUtf8Raw() cannot append lonely surrogates > ----------------------------------------------------------------- > > Key: ELY-139 > URL: https://issues.jboss.org/browse/ELY-139 > Project: WildFly Elytron > Issue Type: Bug > Reporter: Jan Kalina > Assignee: Jan Kalina > Priority: Minor > > ByteStringBuilder cannot append codepoints 0xD8xx (lonely surrogates). It should - StringBuilder.appendCodePoint() work with it. > (Problem is only with uncomplete/nonvalid unicode strings, so it is not critical problem.) > Mentioned in: https://github.com/wildfly-security/wildfly-elytron/pull/101 > *UPDATE:* > ByteStringBuilder encode surrogates correctly by RFC3629 (if we ignore they are prohibited because they are reserved for UTF-16). Conversly StringBuilder and {{(char)}} operator encode D800-D8FF bad as 3F. > Problem is only in appending into ByteStringBuilder constructed as: > {code:xml} > new ByteStringBuilder(new byte[]{}); > {/code} -- This message was sent by Atlassian JIRA (v6.3.11#6341)

10 years, 11 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-583) Drools WB jcr2vfs: make the migration tool work again

by Petr Široký (JIRA)

[ https://issues.jboss.org/browse/DROOLS-583?page=com.atlassian.jira.plugin... ] Petr Široký commented on DROOLS-583: ------------------------------------ Jan resolved this issue a while ago. Thanks! > Drools WB jcr2vfs: make the migration tool work again > ----------------------------------------------------- > > Key: DROOLS-583 > URL: https://issues.jboss.org/browse/DROOLS-583 > Project: Drools > Issue Type: Bug > Affects Versions: 6.2.0.Beta1 > Reporter: Petr Široký > Assignee: Jan Schatteman > Fix For: 6.2.0.Final > > > The current 6.2.0 SNAPSHOTS of the jcr2vfs tool are broken. There seems to some issue with incompatibility with between Drools 5.x and 6.x. > {code} > Asset [Bankruptcy history] with format [brl] is being migrated... > java.lang.ClassCastException: org.drools.core.base.accumulators.BigDecimalSumAccumulateFunction cannot be cast to org.drools.runtime.rule.AccumulateFunction > at org.drools.compiler.PackageBuilderConfiguration.loadAccumulateFunction(PackageBuilderConfiguration.java:530) > at org.drools.compiler.PackageBuilderConfiguration.buildAccumulateFunctionsMap(PackageBuilderConfiguration.java:479) > at org.drools.compiler.PackageBuilderConfiguration.init(PackageBuilderConfiguration.java:194) > at org.drools.compiler.PackageBuilderConfiguration.<init>(PackageBuilderConfiguration.java:165) > {code} > Another very serious issue is that even when the jcr2vfs tests fail, the Jenkins drools-wb CI build succeeds. This needs to be fixed, so that when the tests fail, the build fails too. > I will try to fix the tool in time for 6.2.0.Final. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

10 years, 11 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-583) Drools WB jcr2vfs: make the migration tool work again

by Petr Široký (JIRA)

[ https://issues.jboss.org/browse/DROOLS-583?page=com.atlassian.jira.plugin... ] Petr Široký resolved DROOLS-583. -------------------------------- Fix Version/s: 6.2.0.Final Resolution: Done > Drools WB jcr2vfs: make the migration tool work again > ----------------------------------------------------- > > Key: DROOLS-583 > URL: https://issues.jboss.org/browse/DROOLS-583 > Project: Drools > Issue Type: Bug > Affects Versions: 6.2.0.Beta1 > Reporter: Petr Široký > Assignee: Jan Schatteman > Fix For: 6.2.0.Final > > > The current 6.2.0 SNAPSHOTS of the jcr2vfs tool are broken. There seems to some issue with incompatibility with between Drools 5.x and 6.x. > {code} > Asset [Bankruptcy history] with format [brl] is being migrated... > java.lang.ClassCastException: org.drools.core.base.accumulators.BigDecimalSumAccumulateFunction cannot be cast to org.drools.runtime.rule.AccumulateFunction > at org.drools.compiler.PackageBuilderConfiguration.loadAccumulateFunction(PackageBuilderConfiguration.java:530) > at org.drools.compiler.PackageBuilderConfiguration.buildAccumulateFunctionsMap(PackageBuilderConfiguration.java:479) > at org.drools.compiler.PackageBuilderConfiguration.init(PackageBuilderConfiguration.java:194) > at org.drools.compiler.PackageBuilderConfiguration.<init>(PackageBuilderConfiguration.java:165) > {code} > Another very serious issue is that even when the jcr2vfs tests fail, the Jenkins drools-wb CI build succeeds. This needs to be fixed, so that when the tests fail, the build fails too. > I will try to fix the tool in time for 6.2.0.Final. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

10 years, 11 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira January 2015