[JBoss JIRA] (WFLY-12103) Quickstarts BOM Builder
by Eduardo Martins (Jira)
Eduardo Martins created WFLY-12103:
--------------------------------------
Summary: Quickstarts BOM Builder
Key: WFLY-12103
URL: https://issues.jboss.org/browse/WFLY-12103
Project: WildFly
Issue Type: Enhancement
Components: Quickstarts
Reporter: Eduardo Martins
Assignee: Eduardo Martins
A followup of WFLY-11300, replace WildFly dependency management sync on Quickstarts parent, with a BOM builder, which saves the effort to sync versions, exclusions and transitive dependencies with WildFly.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 2 months
[JBoss JIRA] (WFLY-12102) WildFly BOM Builders
by Eduardo Martins (Jira)
Eduardo Martins created WFLY-12102:
--------------------------------------
Summary: WildFly BOM Builders
Key: WFLY-12102
URL: https://issues.jboss.org/browse/WFLY-12102
Project: WildFly
Issue Type: Enhancement
Components: Quickstarts
Reporter: Eduardo Martins
Assignee: Eduardo Martins
A followup of WFLY-11300, replace WildFly BOMs with BOM builders, which saves the effort to sync versions, exclusions and transitive dependencies with WildFly.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 2 months
[JBoss JIRA] (LOGMGR-130) JDK9 Support
by James Perkins (Jira)
[ https://issues.jboss.org/browse/LOGMGR-130?page=com.atlassian.jira.plugin... ]
James Perkins resolved LOGMGR-130.
----------------------------------
Fix Version/s: 2.1.0.Final
Resolution: Done
> JDK9 Support
> ------------
>
> Key: LOGMGR-130
> URL: https://issues.jboss.org/browse/LOGMGR-130
> Project: JBoss Log Manager
> Issue Type: Feature Request
> Reporter: David Lloyd
> Priority: Major
> Fix For: 2.1.0.Final
>
>
> A few enhancements become possible, desirable, and/or necessary when moving to JDK 9. This is an umbrella parent issue to cover them all.
> Note that some of these features may require multi-version JAR building, which Maven cannot yet do.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 2 months
[JBoss JIRA] (ELY-1634) LDAPS referrals broken
by Philippe Marschall (Jira)
[ https://issues.jboss.org/browse/ELY-1634?page=com.atlassian.jira.plugin.s... ]
Philippe Marschall commented on ELY-1634:
-----------------------------------------
That is correct, I did not include a test. I could not see how to test this other than with an integration test that includes an LDAP server that does referrals.
> LDAPS referrals broken
> ----------------------
>
> Key: ELY-1634
> URL: https://issues.jboss.org/browse/ELY-1634
> Project: WildFly Elytron
> Issue Type: Bug
> Reporter: Philippe Marschall
> Assignee: Darran Lofthouse
> Priority: Major
> Fix For: 1.7.0.CR1
>
>
> We are having trouble getting LDAPS referrals working with an Elytron LDAP realm. The issue is the following stack trace.
> {code}
> javax.security.sasl.SaslException: ELY05012: Authentication mechanism server-side authentication failed [Caused by org.wildfly.security.auth.server.RealmUnavailableException: ELY01153: Direct LDAP verification failed with DN [redacted] and absolute DN [null]]
> at org.wildfly.security.sasl.plain.PlainSaslServer.evaluateResponse(PlainSaslServer.java:121)
> at org.wildfly.security.sasl.util.AuthenticationCompleteCallbackSaslServerFactory$1.evaluateResponse(AuthenticationCompleteCallbackSaslServerFactory.java:58)
> at org.wildfly.security.sasl.util.AuthenticationTimeoutSaslServerFactory$DelegatingTimeoutSaslServer.evaluateResponse(AuthenticationTimeoutSaslServerFactory.java:106)
> at org.wildfly.security.sasl.util.SecurityIdentitySaslServerFactory$1.evaluateResponse(SecurityIdentitySaslServerFactory.java:59)
> at org.xnio.sasl.SaslUtils.evaluateResponse(SaslUtils.java:245)
> at org.xnio.sasl.SaslUtils.evaluateResponse(SaslUtils.java:217)
> at org.jboss.remoting3.remote.ServerConnectionOpenListener$AuthStepRunnable.run(ServerConnectionOpenListener.java:486)
> at org.jboss.remoting3.EndpointImpl$TrackingExecutor.lambda$execute$0(EndpointImpl.java:926)
> 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:1349)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: org.wildfly.security.auth.server.RealmUnavailableException: ELY01153: Direct LDAP verification failed with DN [redacted] and absolute DN [null]
> at org.wildfly.security.auth.realm.ldap.DirectEvidenceVerifier$1.verifyEvidence(DirectEvidenceVerifier.java:104)
> at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm$LdapRealmIdentity.verifyEvidence(LdapSecurityRealm.java:609)
> at org.wildfly.security.auth.realm.AggregateSecurityRealm$Identity.verifyEvidence(AggregateSecurityRealm.java:155)
> at org.wildfly.security.auth.server.ServerAuthenticationContext$NameAssignedState.verifyEvidence(ServerAuthenticationContext.java:1977)
> at org.wildfly.security.auth.server.ServerAuthenticationContext.verifyEvidence(ServerAuthenticationContext.java:759)
> at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handleOne(ServerAuthenticationContext.java:992)
> at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handleOne(ServerAuthenticationContext.java:902)
> at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handle(ServerAuthenticationContext.java:839)
> at org.wildfly.security.sasl.util.SSLQueryCallbackHandler.handle(SSLQueryCallbackHandler.java:60)
> at org.wildfly.security.sasl.util.TrustManagerSaslServerFactory.lambda$createSaslServer$0(TrustManagerSaslServerFactory.java:96)
> at org.wildfly.security.sasl.plain.PlainSaslServer.evaluateResponse(PlainSaslServer.java:117)
> ... 12 more
> Caused by: javax.naming.CommunicationException: ldap.acme.com:636 [Root exception is java.lang.ClassNotFoundException: org.wildfly.security.auth.realm.ldap.ThreadLocalSSLSocketFactory from [Module "org.wildfly.extension.io" version 5.0.0.Final from local module loader @7586beff (finder: local module finder @3b69e7d1 (roots: redacted))]]
> at com.sun.jndi.ldap.Connection.<init>(Connection.java:226)
> at com.sun.jndi.ldap.LdapClient.<init>(LdapClient.java:137)
> at com.sun.jndi.ldap.LdapClient.getInstance(LdapClient.java:1615)
> at com.sun.jndi.ldap.LdapCtx.connect(LdapCtx.java:2749)
> at com.sun.jndi.ldap.LdapCtx.ensureOpen(LdapCtx.java:2699)
> at com.sun.jndi.ldap.LdapCtx.ensureOpen(LdapCtx.java:2673)
> at com.sun.jndi.ldap.LdapCtx.reconnect(LdapCtx.java:2669)
> at org.wildfly.security.auth.realm.ldap.DelegatingLdapContext.reconnect(DelegatingLdapContext.java:181)
> at org.wildfly.security.auth.realm.ldap.DirectEvidenceVerifier$1.verifyEvidence(DirectEvidenceVerifier.java:97)
> ... 22 more
> Caused by: java.lang.ClassNotFoundException: org.wildfly.security.auth.realm.ldap.ThreadLocalSSLSocketFactory from [Module "org.wildfly.extension.io" version 5.0.0.Final from local module loader @7586beff (finder: local module finder @3b69e7d1 (roots: redacted))]
> at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:255)
> at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:410)
> at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:398)
> at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:116)
> at java.lang.Class.forName0(Native Method)
> at java.lang.Class.forName(Class.java:348)
> at com.sun.jndi.ldap.VersionHelper12.loadClass(VersionHelper12.java:72)
> at com.sun.jndi.ldap.Connection.createSocket(Connection.java:281)
> at com.sun.jndi.ldap.Connection.<init>(Connection.java:203)
> ... 30 more
> {code}
> As you can see the Sun/Oracle LDAP classes try to load the class {{org.wildfly.security.auth.realm.ldap.ThreadLocalSSLSocketFactory}} using the TCCL which is the {{org.wildfly.extension.io}} module loader. This will not work as ThreadLocalSSLSocketFactor is in the module {{org.wildfy.security.elytron-private}}.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 2 months
[JBoss JIRA] (DROOLS-4049) PMML files are not listed in Library only in Project Explorer
by Michael Anstis (Jira)
[ https://issues.jboss.org/browse/DROOLS-4049?page=com.atlassian.jira.plugi... ]
Michael Anstis commented on DROOLS-4049:
----------------------------------------
[~tirelli] Would you consider PMML to be closer to "Model" than "Decision" (we only have categories "Decision", "Form", "Model", "Others", "Optimisation", "Process" and "Undefined" although we could add another just for PMML..)?
> PMML files are not listed in Library only in Project Explorer
> -------------------------------------------------------------
>
> Key: DROOLS-4049
> URL: https://issues.jboss.org/browse/DROOLS-4049
> Project: Drools
> Issue Type: Enhancement
> Components: PMML
> Affects Versions: 7.21.0.Final
> Reporter: Matteo Mortari
> Assignee: Michael Anstis
> Priority: Critical
> Labels: drools-tools
> Attachments: image-2019-05-17-15-43-45-741.png, image-2019-05-17-15-44-06-544.png, image-2019-05-17-15-44-30-629.png, test_scorecard.pmml
>
>
> As title I upload a .pmml file
> !image-2019-05-17-15-43-45-741.png|thumbnail!
> it does not appear in asset view despite refresh and multiple time waiting:
> !image-2019-05-17-15-44-06-544.png|thumbnail!
> the only way to check if the file is there is to open another editor at random and check in file explorer:
> !image-2019-05-17-15-44-30-629.png|thumbnail!
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 2 months
[JBoss JIRA] (DROOLS-4051) Wrong compiled type definition
by Stéphane Tondini (Jira)
[ https://issues.jboss.org/browse/DROOLS-4051?page=com.atlassian.jira.plugi... ]
Stéphane Tondini commented on DROOLS-4051:
------------------------------------------
Thank you [~mfusco].
I found it in the doc https://docs.jboss.org/drools/release/7.0.0.Final/drools-docs/html_single
Chapter 8.5.1
> Wrong compiled type definition
> ------------------------------
>
> Key: DROOLS-4051
> URL: https://issues.jboss.org/browse/DROOLS-4051
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 7.21.0.Final
> Reporter: Stéphane Tondini
> Assignee: Mario Fusco
> Priority: Major
>
> I defined a drl file that declare a type like :
> {code}
> package com.test.rules.model.process;
> // Process related objects
> declare Process
> caseRef : String @key
> owner : String @key
> end
> {code}
> At rules compile time, Drools throws the following exception :
> {code}
> Caused by: java.lang.IllegalArgumentException: Error parsing bootstrap resources : New declaration of java.lang.Process can't declare a different set of fields
> existing : []
> declared : [caseRef]
> diff : [++caseRef]
> Unable to process type Process
> {code}
> Drools compiles *java.lang.Process* instead of my customized type.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 2 months
[JBoss JIRA] (DROOLS-4051) Wrong compiled type definition
by Stéphane Tondini (Jira)
[ https://issues.jboss.org/browse/DROOLS-4051?page=com.atlassian.jira.plugi... ]
Stéphane Tondini edited comment on DROOLS-4051 at 5/20/19 3:44 PM:
-------------------------------------------------------------------
It seems the following definition works :
{code}
package com.test.rules.model.process;
// Process related objects
declare com.test.rules.model.process.Process
caseRef : String @key
owner : String @key
end
{code}
was (Author: stondini):
It seems the folloeing definition works :
{code}
package com.test.rules.model.process;
// Process related objects
declare com.test.rules.model.process.Process
caseRef : String @key
owner : String @key
end
{code}
> Wrong compiled type definition
> ------------------------------
>
> Key: DROOLS-4051
> URL: https://issues.jboss.org/browse/DROOLS-4051
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 7.21.0.Final
> Reporter: Stéphane Tondini
> Assignee: Mario Fusco
> Priority: Major
>
> I defined a drl file that declare a type like :
> {code}
> package com.test.rules.model.process;
> // Process related objects
> declare Process
> caseRef : String @key
> owner : String @key
> end
> {code}
> At rules compile time, Drools throws the following exception :
> {code}
> Caused by: java.lang.IllegalArgumentException: Error parsing bootstrap resources : New declaration of java.lang.Process can't declare a different set of fields
> existing : []
> declared : [caseRef]
> diff : [++caseRef]
> Unable to process type Process
> {code}
> Drools compiles *java.lang.Process* instead of my customized type.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 2 months
[JBoss JIRA] (DROOLS-4057) Unable to use CSV in a ruleTemplate
by Karina Varela (Jira)
Karina Varela created DROOLS-4057:
-------------------------------------
Summary: Unable to use CSV in a ruleTemplate
Key: DROOLS-4057
URL: https://issues.jboss.org/browse/DROOLS-4057
Project: Drools
Issue Type: Bug
Components: decision tables
Affects Versions: 6.5.0.Final, 7.21.0.Final
Environment: Any Java env
Reporter: Karina Varela
Assignee: Mario Fusco
Attachments: csv_import_test.tar.gz
I believe there is a bug where you cannot use a CSV file to use as a decision table to drive a ruleTemplate. Our issue appears to be a duplicate of the one mentioned in this pull request -https://github.com/kiegroup/drools/pull/1920
The drools version we're using is 6.50.FINAL, but the reproducer I've attached is for the latest released version.
We'd like to move away from binary files as they're opaque to most version control and it makes branching difficult.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 2 months
[JBoss JIRA] (LOGMGR-246) Wildfly 16 incorrect working log zip rotator
by James Perkins (Jira)
[ https://issues.jboss.org/browse/LOGMGR-246?page=com.atlassian.jira.plugin... ]
James Perkins updated LOGMGR-246:
---------------------------------
Git Pull Request: https://github.com/jboss-logging/jboss-logmanager/pull/252, https://github.com/jboss-logging/jboss-logmanager/pull/253, https://github.com/jboss-logging/jboss-logmanager/pull/254, https://github.com/jboss-logging/jboss-logmanager/pull/255, https://github.com/jboss-logging/jboss-logmanager/pull/256 (was: https://github.com/jboss-logging/jboss-logmanager/pull/252, https://github.com/jboss-logging/jboss-logmanager/pull/253, https://github.com/jboss-logging/jboss-logmanager/pull/254)
> Wildfly 16 incorrect working log zip rotator
> --------------------------------------------
>
> Key: LOGMGR-246
> URL: https://issues.jboss.org/browse/LOGMGR-246
> Project: JBoss Log Manager
> Issue Type: Bug
> Components: core
> Environment: Windows,
> Oracle JDK 8
> Reporter: Igor Dmitriev
> Assignee: James Perkins
> Priority: Major
> Fix For: 1.5.10.Final, 2.0.12.Final, 2.1.11.Final, 2.2.0.Final, 3.0.0.Final
>
>
> My logging profile configuration is:
> 1)
> {code:xml}
> <periodic-size-rotating-file-handler name="FILE" rotate-on-boot="false" autoflush="true">
> <level name="ALL"/>
> <file relative-to="jboss.server.log.dir" path="corp.log"/>
> <rotate-size value="300k"/>
> <max-backup-index value="10000"/>
> <suffix value=".yyyy-MM-dd.zip"/>
> <append value="true"/>
> </periodic-size-rotating-file-handler>
> {code}
> File corp.log increase it size permanently, even after new corp.log.yyyy-MM-dd.N.zip file created. Due it, each .zip archive contain same corp.log with maximum current size.
> 2)
> {code:xml}
> <periodic-size-rotating-file-handler name="FILE2" rotate-on-boot="true" autoflush="true">
> <level name="ALL"/>
> <file relative-to="jboss.server.log.dir" path="corp.log"/>
> <rotate-size value="300k"/>
> <max-backup-index value="10000"/>
> <suffix value=".yyyy-MM-dd.zip"/>
> <append value="false"/>
> </periodic-size-rotating-file-handler>
> {code}
> All work as expected, except each time corp.log reach 300k, appear pair .zip files with same content?
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 2 months
[JBoss JIRA] (WFLY-11218) IIOP call does not work with transaction started on client side when run on IBM JDK
by James Perkins (Jira)
[ https://issues.jboss.org/browse/WFLY-11218?page=com.atlassian.jira.plugin... ]
James Perkins updated WFLY-11218:
---------------------------------
Labels: blocker-WF18 (was: blocker-WF17 blocker-WF18)
> IIOP call does not work with transaction started on client side when run on IBM JDK
> -----------------------------------------------------------------------------------
>
> Key: WFLY-11218
> URL: https://issues.jboss.org/browse/WFLY-11218
> Project: WildFly
> Issue Type: Bug
> Components: IIOP
> Affects Versions: 14.0.0.Final, 15.0.0.Beta1
> Environment: IBM JDK 8
> Reporter: Ivan Straka
> Assignee: Tomasz Adamski
> Priority: Blocker
> Labels: blocker-WF18
>
> Issue is valid only for IBM JDK 8...scenario works on oracle jdk 8 and 11 and openjdk 8.
> Scenario (using CORBA):
> # start transaction
> # lookup
> # IIOP call
> # EJB perform a basic operation and return (no failure is expected)
> IIOP call fails with following exception:
> {code:java}
> java.lang.NullPointerException: null
> at com.sun.corba.se.impl.protocol.CorbaMessageMediatorImpl.sentFullMessage(CorbaMessageMediatorImpl.java:429)
> at com.sun.corba.se.impl.protocol.CorbaMessageMediatorImpl.sendCancelRequestIfFinalFragmentNotSent(CorbaMessageMediatorImpl.java:394)
> at com.sun.corba.se.impl.protocol.CorbaClientRequestDispatcherImpl.endRequest(CorbaClientRequestDispatcherImpl.java:895)
> at com.sun.corba.se.impl.protocol.CorbaClientDelegateImpl.releaseReply(CorbaClientDelegateImpl.java:167)
> at com.sun.corba.se.impl.protocol.CorbaClientDelegateImpl.is_a(CorbaClientDelegateImpl.java:253)
> at org.omg.CORBA.portable.ObjectImpl._is_a(ObjectImpl.java:139)
> at org.omg.CosNaming.NamingContextHelper.narrow(NamingContextHelper.java:91)
> at com.sun.jndi.cosnaming.CNCtx.setOrbAndRootContext(CNCtx.java:408)
> at com.sun.jndi.cosnaming.CNCtx.initOrbAndRootContext(CNCtx.java:274)
> at com.sun.jndi.cosnaming.CNCtx.<init>(CNCtx.java:132)
> at com.sun.jndi.cosnaming.CNCtxFactory.getInitialContext(CNCtxFactory.java:61)
> at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:695)
> at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:324)
> at javax.naming.InitialContext.init(InitialContext.java:255)
> at javax.naming.InitialContext.<init>(InitialContext.java:227)
> at org.jboss.as.test.jbossts.client.utils.TxUtil.lookupIIOP(TxUtil.java:93)
> at org.jboss.as.test.jbossts.client.utils.TxUtil.lookupIIOP(TxUtil.java:103)
> at org.jboss.as.test.jbossts.crashrec.test.JMSCrashRecoveryTestCase.lookupCrashBeanOverIIOP(JMSCrashRecoveryTestCase.java:164)
> at org.jboss.as.test.jbossts.crashrec.test.JMSCrashRecoveryTestCase.callCrashTest(JMSCrashRecoveryTestCase.java:126)
> {code}
> When transaction is not started on client side, IIOP call works smoothly.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 2 months