August 2017 - jboss-jira - Jboss List Archives

[JBoss JIRA] (ELY-1331) Elytron GS2-KRB5 SASL mechanism implementation throws NullPointerException on IBM JDK

by Jan Kalina (JIRA)

[ https://issues.jboss.org/browse/ELY-1331?page=com.atlassian.jira.plugin.s... ] Jan Kalina closed ELY-1331. --------------------------- Resolution: Migrated to another ITS Considered IBM JDK issue and now tracked in: https://bugzilla.redhat.com/show_bug.cgi?id=1481103 > Elytron GS2-KRB5 SASL mechanism implementation throws NullPointerException on IBM JDK > ------------------------------------------------------------------------------------- > > Key: ELY-1331 > URL: https://issues.jboss.org/browse/ELY-1331 > Project: WildFly Elytron > Issue Type: Bug > Reporter: Josef Cacek > Priority: Blocker > > The Elytron GS2-KRB5 SASL mechanism doesn't work on IBM JDK. When GSSAPI is used the call works. > If a user tries to use the GS2-KRB5, then the connection hangs until it times out. > Following NPE comes on the client: > {noformat} > java.lang.NullPointerException > at com.ibm.security.krb5.internal.HostAddress.<init>(HostAddress.java:62) > at com.ibm.security.jgss.mech.krb5.Z.<init>(Z.java:71) > at com.ibm.security.jgss.mech.krb5.g.setChannelBinding(g.java:1108) > at com.ibm.security.jgss.GSSContextImpl.setChannelBinding(GSSContextImpl.java:287) > at org.wildfly.security.sasl.gs2.Gs2SaslClient.<init>(Gs2SaslClient.java:120) > at org.wildfly.security.sasl.gs2.Gs2SaslClientFactory.createSaslClient(Gs2SaslClientFactory.java:116) > at org.wildfly.security.sasl.util.SecurityProviderSaslClientFactory.createSaslClient(SecurityProviderSaslClientFactory.java:110) > at org.wildfly.security.sasl.util.AbstractDelegatingSaslClientFactory.createSaslClient(AbstractDelegatingSaslClientFactory.java:66) > at org.wildfly.security.sasl.util.ProtocolSaslClientFactory.createSaslClient(ProtocolSaslClientFactory.java:50) > at org.wildfly.security.sasl.util.AbstractDelegatingSaslClientFactory.createSaslClient(AbstractDelegatingSaslClientFactory.java:66) > at org.wildfly.security.sasl.util.ServerNameSaslClientFactory.createSaslClient(ServerNameSaslClientFactory.java:50) > at org.wildfly.security.sasl.util.AbstractDelegatingSaslClientFactory.createSaslClient(AbstractDelegatingSaslClientFactory.java:66) > at org.wildfly.security.sasl.util.PropertiesSaslClientFactory.createSaslClient(PropertiesSaslClientFactory.java:54) > at org.wildfly.security.sasl.util.AbstractDelegatingSaslClientFactory.createSaslClient(AbstractDelegatingSaslClientFactory.java:66) > at org.wildfly.security.sasl.util.ServerNameSaslClientFactory.createSaslClient(ServerNameSaslClientFactory.java:50) > at org.wildfly.security.sasl.util.FilterMechanismSaslClientFactory.createSaslClient(FilterMechanismSaslClientFactory.java:102) > at org.wildfly.security.sasl.util.AbstractDelegatingSaslClientFactory.createSaslClient(AbstractDelegatingSaslClientFactory.java:66) > at org.wildfly.security.sasl.util.LocalPrincipalSaslClientFactory.createSaslClient(LocalPrincipalSaslClientFactory.java:74) > at org.wildfly.security.sasl.util.PrivilegedSaslClientFactory.lambda$createSaslClient$0(PrivilegedSaslClientFactory.java:64) > at org.wildfly.security.sasl.util.PrivilegedSaslClientFactory$$Lambda$77.00000000FC19A650.run(Unknown Source) > at java.security.AccessController.doPrivileged(AccessController.java:686) > at org.wildfly.security.sasl.util.PrivilegedSaslClientFactory.createSaslClient(PrivilegedSaslClientFactory.java:64) > at org.wildfly.security.auth.client.AuthenticationConfiguration.createSaslClient(AuthenticationConfiguration.java:1237) > at org.wildfly.security.auth.client.AuthenticationContextConfigurationClient.createSaslClient(AuthenticationContextConfigurationClient.java:347) > at org.jboss.remoting3.remote.ClientConnectionOpenListener$Capabilities.handleEvent(ClientConnectionOpenListener.java:418) > at org.jboss.remoting3.remote.ClientConnectionOpenListener$Capabilities.handleEvent(ClientConnectionOpenListener.java:242) > at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) > at org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66) > at org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:89) > at org.xnio.nio.WorkerThread.run(WorkerThread.java:571) > {noformat} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ELY-134) Complete API JavaDoc

by Jan Kalina (JIRA)

[ https://issues.jboss.org/browse/ELY-134?page=com.atlassian.jira.plugin.sy... ] Jan Kalina updated ELY-134: --------------------------- Description: All API components and members must be JavaDoc'd. (elytron parts which are not part of API are listed in ELY-681) was:All API components and members must be JavaDoc'd. > Complete API JavaDoc > -------------------- > > Key: ELY-134 > URL: https://issues.jboss.org/browse/ELY-134 > Project: WildFly Elytron > Issue Type: Task > Reporter: David Lloyd > Priority: Blocker > Fix For: 1.2.0.Beta3 > > > All API components and members must be JavaDoc'd. > (elytron parts which are not part of API are listed in ELY-681) -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9260) Upgrade Artemis 1.5.5.jbossorg-007

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFLY-9260?page=com.atlassian.jira.plugin.... ] Brian Stansberry reassigned WFLY-9260: -------------------------------------- Assignee: Brian Stansberry (was: Martyn Taylor) > Upgrade Artemis 1.5.5.jbossorg-007 > ---------------------------------- > > Key: WFLY-9260 > URL: https://issues.jboss.org/browse/WFLY-9260 > Project: WildFly > Issue Type: Component Upgrade > Components: JMS > Reporter: Martyn Taylor > Assignee: Brian Stansberry > Priority: Blocker > -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9260) Upgrade Artemis 1.5.5.jbossorg-007

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFLY-9260?page=com.atlassian.jira.plugin.... ] Brian Stansberry moved JBEAP-12845 to WFLY-9260: ------------------------------------------------ Project: WildFly (was: JBoss Enterprise Application Platform) Key: WFLY-9260 (was: JBEAP-12845) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: JMS (was: ActiveMQ) > Upgrade Artemis 1.5.5.jbossorg-007 > ---------------------------------- > > Key: WFLY-9260 > URL: https://issues.jboss.org/browse/WFLY-9260 > Project: WildFly > Issue Type: Component Upgrade > Components: JMS > Reporter: Martyn Taylor > Assignee: Martyn Taylor > Priority: Blocker > -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3205) Logging does not work in the embedded server

by James Perkins (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3205?page=com.atlassian.jira.plugi... ] James Perkins commented on WFCORE-3205: --------------------------------------- It looks like the jboss-logmanager in the cases of a standalone application may be getting loaded twice. Since the {{org.wildfly.core:wildfly-embedded}} has a dependency on {{org.jboss.logmanager:jboss-logmanager}} using Maven or another build tool may bring in the log manager dependency. This will get loaded on the JVM's default class loader, then the modular class loader will load the library again. Excluding the dependency on the log manager seems to resolve the issue. > Logging does not work in the embedded server > -------------------------------------------- > > Key: WFCORE-3205 > URL: https://issues.jboss.org/browse/WFCORE-3205 > Project: WildFly Core > Issue Type: Bug > Components: Logging > Reporter: James Perkins > Assignee: James Perkins > > When using the {{EmbeddedProcessFactory}} logging does not appear to work. Debugging shows a different {{LogContext}} associated with the loggers than the one associated with the logging subsystem. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3205) Logging does not work in the embedded server

by James Perkins (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3205?page=com.atlassian.jira.plugi... ] James Perkins commented on WFCORE-3205: --------------------------------------- Thanks Eduardo. This would probably work, but the logging subsystem may not be working correctly. Not 100% sure yet though. > Logging does not work in the embedded server > -------------------------------------------- > > Key: WFCORE-3205 > URL: https://issues.jboss.org/browse/WFCORE-3205 > Project: WildFly Core > Issue Type: Bug > Components: Logging > Reporter: James Perkins > Assignee: James Perkins > > When using the {{EmbeddedProcessFactory}} logging does not appear to work. Debugging shows a different {{LogContext}} associated with the loggers than the one associated with the logging subsystem. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (HAWKULARQE-174) Adding link to a VM - MIQ Sprint-67

by Hayk Hovsepyan (JIRA)

[ https://issues.jboss.org/browse/HAWKULARQE-174?page=com.atlassian.jira.pl... ] Hayk Hovsepyan reassigned HAWKULARQE-174: ----------------------------------------- Assignee: Hayk Hovsepyan (was: Michael Foley) > Adding link to a VM - MIQ Sprint-67 > ----------------------------------- > > Key: HAWKULARQE-174 > URL: https://issues.jboss.org/browse/HAWKULARQE-174 > Project: Hawkular QE > Issue Type: Task > Reporter: Matt Mahoney > Assignee: Hayk Hovsepyan > > Enhancement - adding link to a VM also for middleware servers running in domain mode -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (HAWKULARQE-173) UX Improvement - When adding a datasource - MIQ Sprint-67

by Sunil kondkar (JIRA)

[ https://issues.jboss.org/browse/HAWKULARQE-173?page=com.atlassian.jira.pl... ] Sunil kondkar commented on HAWKULARQE-173: ------------------------------------------ Below issue is opened against latest MIQ : https://github.com/ManageIQ/manageiq-providers-hawkular/issues/33 > UX Improvement - When adding a datasource - MIQ Sprint-67 > --------------------------------------------------------- > > Key: HAWKULARQE-173 > URL: https://issues.jboss.org/browse/HAWKULARQE-173 > Project: Hawkular QE > Issue Type: Task > Reporter: Matt Mahoney > Assignee: Sunil kondkar > > From MIQ Sprint-67 Demo: > UX Improvement - When adding a datasource, there is a need to fetch available jdbc drivers from middleware server. If a provider is not running, do not display an exception when fetching jdbc drivers, but show a descriptive warning message and allow the user to close the wizard. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3205) Logging does not work in the embedded server

by Eduardo Martins (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3205?page=com.atlassian.jira.plugi... ] Eduardo Martins commented on WFCORE-3205: ----------------------------------------- The migration tool sets the java environment for JBoss LogManager, using a logging.properties configuration file: https://github.com/wildfly/wildfly-server-migration/blob/master/build/src... https://github.com/wildfly/wildfly-server-migration/blob/master/build/src... and then creates the embedded server like this: https://github.com/wildfly/wildfly-server-migration/blob/master/wildfly10... Everything works fine AFAIK, please note that configuration hides the logs coming from server on the console, these show only on the log file. > Logging does not work in the embedded server > -------------------------------------------- > > Key: WFCORE-3205 > URL: https://issues.jboss.org/browse/WFCORE-3205 > Project: WildFly Core > Issue Type: Bug > Components: Logging > Reporter: James Perkins > Assignee: James Perkins > > When using the {{EmbeddedProcessFactory}} logging does not appear to work. Debugging shows a different {{LogContext}} associated with the loggers than the one associated with the logging subsystem. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1710) Jitting process may randomly fail during multithreaded execution

by Tibor Zimányi (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1710?page=com.atlassian.jira.plugi... ] Tibor Zimányi updated DROOLS-1710: ---------------------------------- Labels: concurrency jitting (was: jitting) > Jitting process may randomly fail during multithreaded execution > ---------------------------------------------------------------- > > Key: DROOLS-1710 > URL: https://issues.jboss.org/browse/DROOLS-1710 > Project: Drools > Issue Type: Bug > Components: core engine > Reporter: Mario Fusco > Assignee: Mario Fusco > Labels: concurrency, jitting > Fix For: 7.3.0.Final > > > The jitting process assumes that the mvel constraint has been evaluated at least once before it kicks in. This may not be the case during a multithreaded execution (especially when running with many threads and a very low jitting threshold) because the jitting process may start when other threads have already requested the constraint evaluation using the mvel interpreted constraint (thus incrementing the jitting counter) but none of them had enough time to complete it. When this happens the jitting process trying to work on an uncompleted AST throwing internally an exception like the following: > {code} > Exception in thread "drools-worker-1" java.lang.RuntimeException: java.lang.RuntimeException: Null accessor on node: firings > at org.drools.core.rule.constraint.MvelConstraint.executeJitting(MvelConstraint.java:346) > at org.drools.core.rule.constraint.MvelConstraint.access$200(MvelConstraint.java:82) > at org.drools.core.rule.constraint.MvelConstraint$ConditionJitter.run(MvelConstraint.java:313) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:748) > Caused by: java.lang.RuntimeException: Null accessor on node: firings > at org.drools.core.rule.constraint.ConditionAnalyzer.analyzeNode(ConditionAnalyzer.java:302) > at org.drools.core.rule.constraint.ConditionAnalyzer.analyzeSingleCondition(ConditionAnalyzer.java:159) > at org.drools.core.rule.constraint.ConditionAnalyzer.analyzeCondition(ConditionAnalyzer.java:138) > at org.drools.core.rule.constraint.ConditionAnalyzer.analyzeCondition(ConditionAnalyzer.java:109) > at org.drools.core.rule.constraint.MvelConditionEvaluator.getAnalyzedCondition(MvelConditionEvaluator.java:129) > at org.drools.core.rule.constraint.MvelConstraint.executeJitting(MvelConstraint.java:333) > ... 5 more > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 8 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 August 2017