[JBoss JIRA] (ELY-1541) local-kerberos CredentialSource does not work with IBM java
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/ELY-1541?page=com.atlassian.jira.plugin.s... ]
Jan Kalina edited comment on ELY-1541 at 4/5/18 5:01 PM:
---------------------------------------------------------
Ok, I was wrong - we dont need any {{<local-kerberos>}} in elytron client. All you need to use kerberos as client is to use:
{code}
bin/jboss-cli.sh -c --no-local-auth -Djavax.security.auth.useSubjectCredsOnly=false -Djava.security.krb5.conf=/path/krb5.conf :whoami
{code}
When no credential is provided from CredentialSource, GSSContext will obtain it automatically and also correctly. Just need to have KRB5CCNAME env variable set for IBM JDK before:
{code}
export KRB5CCNAME=FILE:/tmp/krb5cc_1000
{code}
This mean {{LocalKerberosCredentialSource}} should be removed (deprecated) from elytron, as it is redundant.
was (Author: honza889):
Ok, I was wrong - we dont need any {{<local-kerberos>}} in elytron client. All you need to use kerberos as client is to use:
{code}
bin/jboss-cli.sh -c --no-local-auth -Djavax.security.auth.useSubjectCredsOnly=false -Djava.security.krb5.conf=/path/krb5.conf :whoami
{code}
For IBM it is sufficient to set KRB5CCNAME env variable before:
{code}
export KRB5CCNAME=FILE:/tmp/krb5cc_1000
{code}
This mean {{LocalKerberosCredentialSource}} should be removed (deprecated) from elytron, as it is redundant.
> local-kerberos CredentialSource does not work with IBM java
> -----------------------------------------------------------
>
> Key: ELY-1541
> URL: https://issues.jboss.org/browse/ELY-1541
> Project: WildFly Elytron
> Issue Type: Bug
> Components: Credentials
> Affects Versions: 1.2.3.Final
> Reporter: Jan Kalina
> Assignee: Jan Kalina
> Labels: ibm-java
>
> When trying to connect as with Oracle JDK, following error occure:
> {code}
> Failed to connect to the controller: Unable to authenticate against controller at localhost:9990: ELY05053: Callback handler failed for unknown reason: java.lang.reflect.UndeclaredThrowableException: org.ietf.jgss.GSSException, major code: 11, minor code: 0
> major string: General failure, unspecified at GSSAPI level
> minor string: Cannot get credential for principal default principal
> {code}
> -This is probably related to missing *useDefaultCcache* JAAS config (false by default):-
> https://www.ibm.com/support/knowledgecenter/en/SSYKE2_6.0.0/com.ibm.java....
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 3 months
[JBoss JIRA] (ELY-1541) local-kerberos CredentialSource does not work with IBM java
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/ELY-1541?page=com.atlassian.jira.plugin.s... ]
Jan Kalina commented on ELY-1541:
---------------------------------
Ok, I was wrong - we dont need any {{<local-kerberos>}} in elytron client. All you need to use kerberos as client is to use:
{code}
bin/jboss-cli.sh -c --no-local-auth -Djavax.security.auth.useSubjectCredsOnly=false -Djava.security.krb5.conf=/path/krb5.conf :whoami
{code}
For IBM it is sufficient to set KRB5CCNAME env variable before:
{code}
export KRB5CCNAME=FILE:/tmp/krb5cc_1000
{code}
This mean {{LocalKerberosCredentialSource}} should be removed (deprecated) from elytron, as it is redundant.
> local-kerberos CredentialSource does not work with IBM java
> -----------------------------------------------------------
>
> Key: ELY-1541
> URL: https://issues.jboss.org/browse/ELY-1541
> Project: WildFly Elytron
> Issue Type: Bug
> Components: Credentials
> Affects Versions: 1.2.3.Final
> Reporter: Jan Kalina
> Assignee: Jan Kalina
> Labels: ibm-java
>
> When trying to connect as with Oracle JDK, following error occure:
> {code}
> Failed to connect to the controller: Unable to authenticate against controller at localhost:9990: ELY05053: Callback handler failed for unknown reason: java.lang.reflect.UndeclaredThrowableException: org.ietf.jgss.GSSException, major code: 11, minor code: 0
> major string: General failure, unspecified at GSSAPI level
> minor string: Cannot get credential for principal default principal
> {code}
> -This is probably related to missing *useDefaultCcache* JAAS config (false by default):-
> https://www.ibm.com/support/knowledgecenter/en/SSYKE2_6.0.0/com.ibm.java....
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 3 months
[JBoss JIRA] (WFLY-10179) Glassfish to WildFly throw error while starting application "No ejb found with interface of type"
by Sana Korejo (JIRA)
Sana Korejo created WFLY-10179:
----------------------------------
Summary: Glassfish to WildFly throw error while starting application "No ejb found with interface of type"
Key: WFLY-10179
URL: https://issues.jboss.org/browse/WFLY-10179
Project: WildFly
Issue Type: Bug
Components: EJB
Affects Versions: 8.0.0.Final
Reporter: Sana Korejo
Priority: Blocker
Application was working fine with Glassfish 3+ but on migrating it to WildFly 8 it is throwing following error while running. Application is shown in deployments, and postgressql jar too is existing in deployments. Java 6 is used.
JBAS014671: Failed services => { jboss.deployment.unit.\"mywar.file.SNAPSHOT.war\".INSTALL" => "org.jboss.msc.service.StartException in service jboss.deployment.unit.\"mywar.file.SNAPSHOT.war\".INSTALL" JBAS018733: Failed to process phase INSTALL of deployment \"mywar.file.SNAPSHOT.war\" Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: JBAS014544: No EJB found with interface of type "my.services.UserFacade" for binding my.package.RefFacade/userService"},
JBAS014771: Services with missing/ unavailable dependencies => ["jboss.deployment.unit.\"mywar.file.SNAPSHOT.war\".weld.weldClassIntrospector is missing ["jboss.deployment.unit.\"mywar.file.SNAPSHOT.war\".beanmanager]"]}
What can be the issue and how to fix it?
Like (0) • Reply • Share
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 3 months
[JBoss JIRA] (WFLY-10178) Introduce general support for MR JARs into parent POM
by David Lloyd (JIRA)
David Lloyd created WFLY-10178:
----------------------------------
Summary: Introduce general support for MR JARs into parent POM
Key: WFLY-10178
URL: https://issues.jboss.org/browse/WFLY-10178
Project: WildFly
Issue Type: Enhancement
Components: Build System
Reporter: David Lloyd
Assignee: David Lloyd
Backing issue for design proposal to introduce MR JAR support into jboss-parent, so WFLY, WFCORE, and all other subprojects which consume jboss-parent can support MR JARs without any extra work.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 3 months
[JBoss JIRA] (SWSQE-124) Fix or replace the CNCF CI OpenShift Cluster
by Kevin Earls (JIRA)
Kevin Earls created SWSQE-124:
---------------------------------
Summary: Fix or replace the CNCF CI OpenShift Cluster
Key: SWSQE-124
URL: https://issues.jboss.org/browse/SWSQE-124
Project: Kiali QE
Issue Type: QE Task
Reporter: Kevin Earls
Assignee: Matt Mahoney
As we've discussed in email, the CNCF CI OpenShift cluster is currently in a state where deleting some resources is impossible, which makes it impossible to run Jenkins tests. I first saw this when a test tried to delete ElasticSearch. Then after a cluster restart I saw the same problem with Cassandra.
We either need to figure out how to resolve the problem, or replace the cluster.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 3 months
[JBoss JIRA] (DROOLS-2455) Missing beta node sharing
by Mario Fusco (JIRA)
[ https://issues.jboss.org/browse/DROOLS-2455?page=com.atlassian.jira.plugi... ]
Mario Fusco resolved DROOLS-2455.
---------------------------------
Resolution: Done
Fixed by https://github.com/kiegroup/drools/commit/cf8de3f25ab97132c96cbc9a80d1d4c...
> Missing beta node sharing
> -------------------------
>
> Key: DROOLS-2455
> URL: https://issues.jboss.org/browse/DROOLS-2455
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Reporter: Mario Fusco
> Assignee: Mario Fusco
>
> The constraints of a beta node are reordered (based on their indexability) only when the node is attached to the rete network. This means that when a second not yet attached node is compared to the former one it is found not equal (and then not shared) because of the different constraints ordering as demonstrated by the following test case
> {code}
> @Test
> public void testShareBetaWithConstraintReordering() {
> String str =
> "import " + Person.class.getCanonicalName() + ";" +
> "rule R1 when\n" +
> " $s : String()\n" +
> " $p : Person(name != $s, age == $s.length)\n" +
> "then\n" +
> "end\n" +
> "rule R2 when\n" +
> " $s : String()\n" +
> " $p : Person(name != $s, age == $s.length)\n" +
> "then\n" +
> "end";
> KieSession ksession = getKieSession( str );
> assertEquals( 1, ReteDumper.collectNodes( ksession ).stream().filter( BetaNode.class::isInstance ).count() );
> EntryPointNode epn = (( InternalKnowledgeBase ) ksession.getKieBase()).getRete().getEntryPointNodes().values().iterator().next();
> ObjectTypeNode otn = epn.getObjectTypeNodes().get( new ClassObjectType( Person.class ) );
> assertEquals( 1, otn.getSinks().length );
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 3 months