[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
[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
[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
[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
[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
[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
[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