[JBoss JIRA] (ELY-1492) java.nio.file.InvalidPathException: Illegal char ':' at krb5.conf
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/ELY-1492?page=com.atlassian.jira.plugin.s... ]
Jan Kalina updated ELY-1492:
----------------------------
Labels: tests windows (was: )
> java.nio.file.InvalidPathException: Illegal char ':' at krb5.conf
> -----------------------------------------------------------------
>
> Key: ELY-1492
> URL: https://issues.jboss.org/browse/ELY-1492
> Project: WildFly Elytron
> Issue Type: Bug
> Components: Testsuite
> Affects Versions: 1.2.0.Beta11
> Reporter: Martin Choma
> Assignee: Jan Kalina
> Labels: tests, windows
>
> This occures in TS on JDK9 on Windows in tests:
> * org.wildfly.security.sasl.gssapi.CommunicationSuiteChild
> * org.wildfly.security.sasl.gs2.Gs2SuiteChild
> {noformat}
> javax.security.auth.login.LoginException:
> java.nio.file.InvalidPathException: Illegal char <:> at index 2: /W:/workspace/wildfly-elytron-unit-tests/4ad7c91f/wildfly-elytron/target/test-classes/krb5.conf
> at java.base/sun.nio.fs.WindowsPathParser.normalize(WindowsPathParser.java:182)
> at java.base/sun.nio.fs.WindowsPathParser.parse(WindowsPathParser.java:153)
> at java.base/sun.nio.fs.WindowsPathParser.parse(WindowsPathParser.java:77)
> at java.base/sun.nio.fs.WindowsPath.parse(WindowsPath.java:92)
> at java.base/sun.nio.fs.WindowsFileSystem.getPath(WindowsFileSystem.java:229)
> at java.base/java.nio.file.Paths.get(Paths.java:84)
> at java.security.jgss/sun.security.krb5.Config.lambda$loadConfigFile$0(Config.java:639)
> at java.base/java.security.AccessController.doPrivileged(Native Method)
> at java.base/java.security.AccessController.doPrivileged(AccessController.java:429)
> at java.security.jgss/sun.security.krb5.Config.loadConfigFile(Config.java:638)
> at java.security.jgss/sun.security.krb5.Config.<init>(Config.java:176)
> at java.security.jgss/sun.security.krb5.Config.refresh(Config.java:115)
> at jdk.security.auth/com.sun.security.auth.module.Krb5LoginModule.login(Krb5LoginModule.java:528)
> at java.base/javax.security.auth.login.LoginContext.invoke(LoginContext.java:726)
> at java.base/javax.security.auth.login.LoginContext.access$000(LoginContext.java:194)
> at java.base/javax.security.auth.login.LoginContext$4.run(LoginContext.java:665)
> at java.base/javax.security.auth.login.LoginContext$4.run(LoginContext.java:663)
> at java.base/java.security.AccessController.doPrivileged(Native Method)
> at java.base/javax.security.auth.login.LoginContext.invokePriv(LoginContext.java:663)
> at java.base/javax.security.auth.login.LoginContext.login(LoginContext.java:574)
> at org.wildfly.security.sasl.gssapi.JaasUtil.login(JaasUtil.java:71)
> at org.wildfly.security.sasl.gssapi.JaasUtil.loginClient(JaasUtil.java:53)
> at org.wildfly.security.sasl.gs2.Gs2SuiteChild.init(Gs2SuiteChild.java:102)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:564)
> at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> at mockit.integration.junit4.internal.JUnit4TestRunnerDecorator.executeClassMethod(JUnit4TestRunnerDecorator.java:92)
> at mockit.integration.junit4.internal.JUnit4TestRunnerDecorator.invokeExplosively(JUnit4TestRunnerDecorator.java:30)
> at mockit.integration.junit4.internal.MockFrameworkMethod.invokeExplosively(MockFrameworkMethod.java:37)
> at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java)
> at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:24)
> at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at org.junit.runners.Suite.runChild(Suite.java:128)
> at org.junit.runners.Suite.runChild(Suite.java:27)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:367)
> at org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:274)
> at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:238)
> at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:161)
> at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:290)
> at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:242)
> at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:121)
> at java.base/javax.security.auth.login.LoginContext.invoke(LoginContext.java:821)
> at java.base/javax.security.auth.login.LoginContext.access$000(LoginContext.java:194)
> at java.base/javax.security.auth.login.LoginContext$4.run(LoginContext.java:665)
> at java.base/javax.security.auth.login.LoginContext$4.run(LoginContext.java:663)
> at java.base/java.security.AccessController.doPrivileged(Native Method)
> at java.base/javax.security.auth.login.LoginContext.invokePriv(LoginContext.java:663)
> at java.base/javax.security.auth.login.LoginContext.login(LoginContext.java:574)
> at org.wildfly.security.sasl.gssapi.JaasUtil.login(JaasUtil.java:71)
> at org.wildfly.security.sasl.gssapi.JaasUtil.loginClient(JaasUtil.java:53)
> at org.wildfly.security.sasl.gs2.Gs2SuiteChild.init(Gs2SuiteChild.java:102)
> {noformat}
> [1] https://jenkins.hosts.mwqe.eng.bos.redhat.com/hudson/view/EAP7/view/EAP7-...
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 3 months
[JBoss JIRA] (ELY-1494) SecurityException: JCE cannot authenticate the provider WildFlyElytron
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/ELY-1494?page=com.atlassian.jira.plugin.s... ]
Jan Kalina updated ELY-1494:
----------------------------
Labels: hp-ux tests (was: )
> SecurityException: JCE cannot authenticate the provider WildFlyElytron
> ----------------------------------------------------------------------
>
> Key: ELY-1494
> URL: https://issues.jboss.org/browse/ELY-1494
> Project: WildFly Elytron
> Issue Type: Bug
> Components: Testsuite
> Affects Versions: 1.2.0.Beta11
> Reporter: Martin Choma
> Assignee: Jan Kalina
> Labels: hp-ux, tests
>
> This happens on HP-UX in KeyStoreCredentialStoreTest. It probably related to ELY-1295 fix. Fix have to take HP-UX JDK in account as well.
>
> Btw. Isn't there more elegant way how to enable tests for PKCS12. Necessary hack seems to be problematic.
> {noformat}
> java.lang.SecurityException: JCE cannot authenticate the provider WildFlyElytron
> at javax.crypto.JceSecurity.getInstance(JceSecurity.java:118)
> at javax.crypto.SecretKeyFactory.getInstance(SecretKeyFactory.java:244)
> at org.wildfly.security.credential.store.impl.KeyStoreCredentialStoreTest.installWildFlyElytronProvider(KeyStoreCredentialStoreTest.java:117)
> Caused by: java.lang.SecurityException: Cannot verify jar:file:/hudson_workspace/workspace/wildfly-elytron-unit-tests/8cc93d85/wildfly-elytron/target/classes/!/
> at javax.crypto.JarVerifier.verifySingleJar(JarVerifier.java:448)
> at javax.crypto.JarVerifier.verifyJars(JarVerifier.java:363)
> at javax.crypto.JarVerifier.verify(JarVerifier.java:289)
> at javax.crypto.JceSecurity.verifyProviderJar(JceSecurity.java:164)
> at javax.crypto.JceSecurity.getVerificationResult(JceSecurity.java:190)
> at javax.crypto.JceSecurity.getInstance(JceSecurity.java:114)
> ... 2 more
> Caused by: java.security.PrivilegedActionException: java.io.FileNotFoundException: /hudson_workspace/workspace/wildfly-elytron-unit-tests/8cc93d85/wildfly-elytron/target/classes (Is a directory)
> at java.security.AccessController.doPrivileged(Native Method)
> at javax.crypto.JarVerifier.verifySingleJar(JarVerifier.java:426)
> ... 7 more
> Caused by: java.io.FileNotFoundException: /hudson_workspace/workspace/wildfly-elytron-unit-tests/8cc93d85/wildfly-elytron/target/classes (Is a directory)
> at java.util.zip.ZipFile.open(Native Method)
> at java.util.zip.ZipFile.<init>(ZipFile.java:225)
> at java.util.zip.ZipFile.<init>(ZipFile.java:155)
> at java.util.jar.JarFile.<init>(JarFile.java:166)
> at java.util.jar.JarFile.<init>(JarFile.java:103)
> at javax.crypto.JarVerifier$2.run(JarVerifier.java:440)
> at javax.crypto.JarVerifier$2.run(JarVerifier.java:427)
> ... 9 more
> {noformat}
> [1] https://jenkins.hosts.mwqe.eng.bos.redhat.com/hudson/view/EAP7/view/EAP7-...
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 3 months
[JBoss JIRA] (DROOLS-2233) DMN: time(date("2017-08-10")) should return 00:00:00z time
by Edson Tirelli (JIRA)
[ https://issues.jboss.org/browse/DROOLS-2233?page=com.atlassian.jira.plugi... ]
Edson Tirelli updated DROOLS-2233:
----------------------------------
Sprint: 2018 Week 03-04
> DMN: time(date("2017-08-10")) should return 00:00:00z time
> ----------------------------------------------------------
>
> Key: DROOLS-2233
> URL: https://issues.jboss.org/browse/DROOLS-2233
> Project: Drools
> Issue Type: Bug
> Components: dmn engine
> Affects Versions: 7.5.0.Final
> Reporter: Tibor Zimányi
> Assignee: Tibor Zimányi
>
> According to the specification in section "10.3.2.3.5 date":
> "Where necessary, including the valuedt function (see 10.3.2.x.6), a date value is considered to be equivalent to a date time value in which the time of day is UTC midnight (00:00:00)."
> Currently the case time(date("2017-08-10")) returns null, because the evaluation ends with DateTimeException, because internally we represent dates as LocalDate class, which doesn't have time part.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 3 months
[JBoss JIRA] (WFCORE-3387) MBeanServer - not returning ManagedBean jboss.as:deployment=* during deployment
by Nuno Godinho de Matos (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3387?page=com.atlassian.jira.plugi... ]
Nuno Godinho de Matos commented on WFCORE-3387:
-----------------------------------------------
Hi Brian,
I would like to comment on your recommendation.
The approach to register the NotificationListener on "JMImplementation:type=MBeanServerDelegate" instead of "jboss.as:deployment=war-name.war"
works like a charm.
I am very sorry to only have given you feedback now, but I could not give priority to this problem.
Please close this Issue, the MBeanServerDelegate works perfectly.
Kindest regards.
> MBeanServer - not returning ManagedBean jboss.as:deployment=* during deployment
> -------------------------------------------------------------------------------
>
> Key: WFCORE-3387
> URL: https://issues.jboss.org/browse/WFCORE-3387
> Project: WildFly Core
> Issue Type: Bug
> Components: JMX
> Affects Versions: 3.0.8.Final
> Reporter: Nuno Godinho de Matos
> Priority: Minor
>
> In wildfly, there is a class of managed beans that are particularly useful to have available during application deployment.
> In partocular beans with Object name (e.g. jboss.as:deployment=someapp-war.war)
> This type of beans can for example sned a JMX Notification that the corresponding application has been deployed.
> While trying to refactor a mechanism that fires an "ApplicationDeployed" event, a mechanism that was blinding registering a Listener on a hard coded ObjectName stopped working consistently once I generalized to hunt for the generalized beans.
> The problem is the following.
> 1. HARD CODED APPROACH:
> If when an application is deploying, during the @Startup logic of an EJB I blindly do something like:
> {panel}
> MBeanServer mBeanServer = createMBeanServer();
> ObjectName targetObject = new ObjectName(objectName);
> mBeanServer.addNotificationListener(targetObject, listener, filter, handback);
> {panel}
> I can successfully register my Listener, without any problem.
> This will work 100% of the time, and after the deployment goes through I can send my notification to the application that the deployment is done.
> I just need to blindly register the listener on:
> jboss.as:deployment=someapp-war.war
> 2. PROBLEM - GENERALIZED APPORACH - QUERY MBEANS
> The Problem now is that once I try to generalize the mechanism, instead of directly doing something like jumping at the "registration", first I need to run a JMX query to hunt of beans:
> jboss.as:deployment=*
> Now I have the problem that I am coming out empty handed, no results.
> Better said, the current approach has two possible behaviors.
> Behavior 1 - Mechanism works:
> - Wildfly is stopped
> - on eclipse I drag and drop the WAR file to the APP server.
> - I start wildfly.
> In this case, the jboss.as:deployment=* will give me the deployed applications.
> The generic mechanism works.
> Behavior 2 - Query comes with no results
> - Wildfly is running
> - no deployments
> - I drag and drop the APP,
> then I get no results.
> Here is a Log snippet from the application when running on apporach 2.
> What you is multiple fluent wait queries.
> You have N tries loop where the query * and hard-coded object name is run. In both scenarios I get no results.
> But i still managed to register a listener If I want and I know the war name.
> {panel}
> ####2017-10-27 11:44:10,171 ThreadId:512 INFO [logger: .impl.jmx.AbstractJmxAppDeploymentNotificationListenerRegistration] - Using HARD_CODED_DIRTY_QUERY: jboss.as:deployment=someapp-war.war - returned: [] <LogContext:Facade> <ServerService Thread Pool -- 339>
> ####2017-10-27 11:44:10,246 ThreadId:512 WARN [logger: .impl.jmx.AbstractJmxAppDeploymentNotificationListenerRegistration] - Query jmx query: jboss.as:deployment=* yielded no results. <LogContext:Facade> <ServerService Thread Pool -- 339>
> ####2017-10-27 11:44:10,253 ThreadId:512 INFO [logger: .impl.jmx.AbstractJmxAppDeploymentNotificationListenerRegistration] - Using HARD_CODED_DIRTY_QUERY: jboss.as:deployment=someapp-war.war - returned: [] <LogContext:Facade> <ServerService Thread Pool -- 339>
> ####2017-10-27 11:44:10,328 ThreadId:512 WARN [logger: .impl.jmx.AbstractJmxAppDeploymentNotificationListenerRegistration] - Query jmx query: jboss.as:deployment=* yielded no results. <LogContext:Facade> <ServerService Thread Pool -- 339>
> ####2017-10-27 11:44:10,332 ThreadId:512 INFO [logger: .impl.jmx.AbstractJmxAppDeploymentNotificationListenerRegistration] - Using HARD_CODED_DIRTY_QUERY: jboss.as:deployment=someapp-war.war - returned: [] <LogContext:Facade> <ServerService Thread Pool -- 339>
> ####2017-10-27 11:44:10,406 ThreadId:512 WARN [logger: .impl.jmx.AbstractJmxAppDeploymentNotificationListenerRegistration] - Query jmx query: jboss.as:deployment=* yielded no results. <LogContext:Facade> <ServerService Thread Pool -- 339>
> ####2017-10-27 11:44:10,409 ThreadId:512 INFO [logger: .impl.jmx.AbstractJmxAppDeploymentNotificationListenerRegistration] - Using HARD_CODED_DIRTY_QUERY: jboss.as:deployment=someapp-war.war - returned: [] <LogContext:Facade> <ServerService Thread Pool -- 339>
> ####2017-10-27 11:44:10,490 ThreadId:512 WARN [AbstractJmxAppDeploymentNotificationListenerRegistration] - Query jmx query: jboss.as:deployment=* yielded no results. <LogContext:Facade> <ServerService Thread Pool -- 339>
> ####2017-10-27 11:44:10,494 ThreadId:512 INFO [AbstractJmxAppDeploymentNotificationListenerRegistration] - Using HARD_CODED_DIRTY_QUERY: jboss.as:deployment=someapp-war.war - returned: [] <LogContext:Facade> <ServerService Thread Pool -- 339>
> ####2017-10-27 11:44:10,569 ThreadId:512 WARN [AbstractJmxAppDeploymentNotificationListenerRegistration] - Query jmx query: jboss.as:deployment=* yielded no results. <LogContext:Facade> <ServerService Thread Pool -- 339>
> ####2017-10-27 11:44:10,574 ThreadId:512 INFO [AbstractJmxAppDeploymentNotificationListenerRegistration] - Using HARD_CODED_DIRTY_QUERY: jboss.as:deployment=someapp-war.war - returned: [] <LogContext:Facade> <ServerService Thread Pool -- 339>
> ####2017-10-27 11:44:10,649 ThreadId:512 WARN [AbstractJmxAppDeploymentNotificationListenerRegistration] - Query jmx query: jboss.as:deployment=* yielded no results. <LogContext:Facade> <ServerService Thread Pool -- 339>
> ####2017-10-27 11:44:10,653 ThreadId:512 INFO [AbstractJmxAppDeploymentNotificationListenerRegistration] - Using HARD_CODED_DIRTY_QUERY: jboss.as:deployment=someapp-war.war - returned: [] <LogContext:Facade> <ServerService Thread Pool -- 339>
> ####2017-10-27 11:44:10,726 ThreadId:512 WARN [AbstractJmxAppDeploymentNotificationListenerRegistration] - Query jmx query: jboss.as:deployment=* yielded no results. <LogContext:Facade> <ServerService Thread Pool -- 339>
> ####2017-10-27 11:44:10,729 ThreadId:512 INFO [AbstractJmxAppDeploymentNotificationListenerRegistration] - Using HARD_CODED_DIRTY_QUERY: jboss.as:deployment=someapp-war.war - returned: [] <LogContext:Facade> <ServerService Thread Pool -- 339>
> ####2017-10-27 11:44:10,802 ThreadId:512 WARN [AbstractJmxAppDeploymentNotificationListenerRegistration] - Query jmx query: jboss.as:deployment=* yielded no results. <LogContext:Facade> <ServerService Thread Pool -- 339>
> ####2017-10-27 11:44:10,804 ThreadId:512 INFO [AbstractJmxAppDeploymentNotificationListenerRegistration] - Using HARD_CODED_DIRTY_QUERY: jboss.as:deployment=someapp-war.war - returned: [] <LogContext:Facade> <ServerService Thread Pool -- 339>
> ####2017-10-27 11:44:10,884 ThreadId:512 WARN [AbstractJmxAppDeploymentNotificationListenerRegistration] - Query jmx query: jboss.as:deployment=* yielded no results. <LogContext:Facade> <ServerService Thread Pool -- 339>
> ####2017-10-27 11:44:10,893 ThreadId:512 INFO [AbstractJmxAppDeploymentNotificationListenerRegistration] - Using HARD_CODED_DIRTY_QUERY: jboss.as:deployment=someapp-war.war - returned: [] <LogContext:Facade> <ServerService Thread Pool -- 339>
> ####2017-10-27 11:44:10,967 ThreadId:512 WARN [AbstractJmxAppDeploymentNotificationListenerRegistration] - Query jmx query: jboss.as:deployment=* yielded no results. <LogContext:Facade> <ServerService Thread Pool -- 339>
> ####2017-10-27 11:44:10,970 ThreadId:512 INFO [AbstractJmxAppDeploymentNotificationListenerRegistration] - Using HARD_CODED_DIRTY_QUERY: jboss.as:deployment=someapp-war.war - returned: [] <LogContext:Facade> <ServerService Thread Pool -- 339>
> ####2017-10-27 11:44:11,044 ThreadId:512 WARN [AbstractJmxAppDeploymentNotificationListenerRegistration] - Query jmx query: jboss.as:deployment=* yielded no results. <LogContext:Facade> <ServerService Thread Pool -- 339>
> ####2017-10-27 11:44:11,050 ThreadId:512 INFO [AbstractJmxAppDeploymentNotificationListenerRegistration] - Using HARD_CODED_DIRTY_QUERY: jboss.as:deployment=someapp-war.war - returned: [] <LogContext:Facade> <ServerService Thread Pool -- 339>
> ####2017-10-27 11:44:11,129 ThreadId:512 WARN [AbstractJmxAppDeploymentNotificationListenerRegistration] - Query jmx query: jboss.as:deployment=* yielded no results. <LogContext:Facade> <ServerService Thread Pool -- 339>
> ####2017-10-27 11:44:11,138 ThreadId:512 INFO [AbstractJmxAppDeploymentNotificationListenerRegistration] - Using HARD_CODED_DIRTY_QUERY: jboss.as:deployment=someapp-war.war - returned: [] <LogContext:Facade> <ServerService Thread Pool -- 339>
> ####2017-10-27 11:44:11,217 ThreadId:512 WARN [AbstractJmxAppDeploymentNotificationListenerRegistration] - Query jmx query: jboss.as:deployment=* yielded no results. <LogContext:Facade> <ServerService Thread Pool -- 339>
> ####2017-10-27 11:44:11,227 ThreadId:512 INFO [AbstractJmxAppDeploymentNotificationListenerRegistration] - Using HARD_CODED_DIRTY_QUERY: jboss.as:deployment=someapp-war.war - returned: [] <LogContext:Facade> <ServerService Thread Pool -- 339>
> ####2017-10-27 11:44:11,304 ThreadId:512 WARN [AbstractJmxAppDeploymentNotificationListenerRegistration] - Query jmx query: jboss.as:deployment=* yielded no results. <LogContext:Facade> <ServerService Thread Pool -- 339>
> ####2017-10-27 11:44:11,312 ThreadId:512 INFO [AbstractJmxAppDeploymentNotificationListenerRegistration] - Using HARD_CODED_DIRTY_QUERY: jboss.as:deployment=someapp-war.war - returned: [] <LogContext:Facade> <ServerService Thread Pool -- 339>
> ####2017-10-27 11:44:11,386 ThreadId:512 WARN [AbstractJmxAppDeploymentNotificationListenerRegistration] - Query jmx query: jboss.as:deployment=* yielded no results. <LogContext:Facade> <ServerService Thread Pool -- 339>
> ####2017-10-27 11:44:11,393 ThreadId:512 INFO [AbstractJmxAppDeploymentNotificationListenerRegistration] - Using HARD_CODED_DIRTY_QUERY: jboss.as:deployment=someapp-war.war - returned: [] <LogContext:Facade> <ServerService Thread Pool -- 339>
> ####2017-10-27 11:44:11,472 ThreadId:512 WARN [AbstractJmxAppDeploymentNotificationListenerRegistration] - Query jmx query: jboss.as:deployment=* yielded no results. <LogContext:Facade> <ServerService Thread Pool -- 339>
> ####2017-10-27 11:44:11,480 ThreadId:512 INFO [AbstractJmxAppDeploymentNotificationListenerRegistration] - Using HARD_CODED_DIRTY_QUERY: jboss.as:deployment=someapp-war.war - returned: [] <LogContext:Facade> <ServerService Thread Pool -- 339>
> ####2017-10-27 11:44:11,559 ThreadId:512 WARN [AbstractJmxAppDeploymentNotificationListenerRegistration] - Query jmx query: jboss.as:deployment=* yielded no results. <LogContext:Facade> <ServerService Thread Pool -- 339>
> ####2017-10-27 11:44:11,568 ThreadId:512 INFO [AbstractJmxAppDeploymentNotificationListenerRegistration] - Using HARD_CODED_DIRTY_QUERY: jboss.as:deployment=someapp-war.war - returned: [] <LogContext:Facade> <ServerService Thread Pool -- 339>
> ####2017-10-27 11:44:11,646 ThreadId:512 WARN [AbstractJmxAppDeploymentNotificationListenerRegistration] - Query jmx query: jboss.as:deployment=* yielded no results. <LogContext:Facade> <ServerService Thread Pool -- 339>
> ####2017-10-27 11:44:11,656 ThreadId:512 INFO [AbstractJmxAppDeploymentNotificationListenerRegistration] - Using HARD_CODED_DIRTY_QUERY: jboss.as:deployment=someapp-war.war - returned: [] <LogContext:Facade> <ServerService Thread Pool -- 339>
> ####2017-10-27 11:44:11,736 ThreadId:512 WARN [AbstractJmxAppDeploymentNotificationListenerRegistration] - Query jmx query: jboss.as:deployment=* yielded no results. <LogContext:Facade> <ServerService Thread Pool -- 339>
> ####2017-10-27 11:44:11,744 ThreadId:512 INFO [AbstractJmxAppDeploymentNotificationListenerRegistration] - Using HARD_CODED_DIRTY_QUERY: jboss.as:deployment=someapp-war.war - returned: [] <LogContext:Facade> <ServerService Thread Pool -- 339>
> ####2017-10-27 11:44:11,822 ThreadId:512 WARN [AbstractJmxAppDeploymentNotificationListenerRegistration] - Query jmx query: jboss.as:deployment=* yielded no results. <LogContext:Facade> <ServerService Thread Pool -- 339>
> ####2017-10-27 11:44:11,831 ThreadId:512 INFO [AbstractJmxAppDeploymentNotificationListenerRegistration] - Using HARD_CODED_DIRTY_QUERY: jboss.as:deployment=someapp-war.war - returned: [] <LogContext:Facade> <ServerService Thread Pool -- 339>
> ####2017-10-27 11:44:11,904 ThreadId:512 WARN [AbstractJmxAppDeploymentNotificationListenerRegistration] - Query jmx query: jboss.as:deployment=* yielded no results. <LogContext:Facade> <ServerService Thread Pool -- 339>
> ####2017-10-27 11:44:11,907 ThreadId:512 INFO [AbstractJmxAppDeploymentNotificationListenerRegistration] - Using HARD_CODED_DIRTY_QUERY: jboss.as:deployment=someapp-war.war - returned: [] <LogContext:Facade> <ServerService Thread Pool -- 339>
> ####2017-10-27 11:44:11,985 ThreadId:512 WARN [AbstractJmxAppDeploymentNotificationListenerRegistration] - Query jmx query: jboss.as:deployment=* yielded no results. <LogContext:Facade> <ServerService Thread Pool -- 339>
> ####2017-10-27 11:44:11,991 ThreadId:512 INFO [AbstractJmxAppDeploymentNotificationListenerRegistration] - Using HARD_CODED_DIRTY_QUERY: jboss.as:deployment=someapp-war.war - returned: [] <LogContext:Facade> <ServerService Thread Pool -- 339>
> ####2017-10-27 11:44:11,991 ThreadId:512 INFO [AbstractJmxAppDeploymentNotificationListenerRegistration] - JMX Query to search for app deployments yielded: [] <LogContext:Facade> <ServerService Thread Pool -- 339>
> ####2017-10-27 11:44:11,991 ThreadId:512 ERROR [AbstractJmxAppDeploymentNotificationListenerRegistration] - No WAR deployment could be found on the managed bean server. The applicatin runtimes that could be found were: [] <LogContext:Facade> <ServerService Thread Pool -- 339>
> ####2017-10-27 11:44:11,992 ThreadId:512 ERROR [AbstractJmxAppDeploymentNotificationListenerRegistration] - Going to add notification listerner using HARD CODED deployment JMX object name <LogContext:Facade> <ServerService Thread Pool -- 339>
> ####2017-10-27 11:44:11,992 ThreadId:512 INFO [AbstractJmxAppDeploymentNotificationListenerRegistration] - Going to register a jmx notification listener on the status of the deployed application: jboss.as:deployment=someapp-war.war <LogContext:Facade> <ServerService Thread Pool -- 339>
> ####2017-10-27 11:44:11,994 ThreadId:512 ERROR [AbstractJmxAppDeploymentNotificationListenerRegistration] - Skipping registration of NotificationLister on WAR application runtime, managed bean could not be found.This has the implication that the application ready event will not be fired after the deployment completes. <LogContext:Facade> <ServerService Thread Pool -- 339>
> ####2017-10-27 11:44:11,995 ThreadId:512 INFO [WildflyJmxAppDeploymentNotificationListenerRegistration] - <- WildflyJmxAppDeploymentNotificationListenerRegistration.registerNotificationLister {2092 ms} <LogContext:Facade> <ServerService Thread Pool -- 339>
> {panel}
> I can try to create a sample application to reproduce this.
> I would expect that before the @Startup logic is triggered on any EJB, I consistenly will have on the MBean server the deployment managemend bean for the WAR whose deployment is currently ongoing - regardless of whether I start the APP serer with the WAr already in or if I have just added the WAr file.
> And in effect, since the "registration mechanims of a listener always works - if you already know the WAR file name ... then it kind means that the Managed bean is in effect in the MBean serer but somehow not visible.
> Many thanks for any help on this.
> I will try to give you a sample application for analysis.
> Kindest regards.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 3 months
[JBoss JIRA] (ELY-1494) SecurityException: JCE cannot authenticate the provider WildFlyElytron
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/ELY-1494?page=com.atlassian.jira.plugin.s... ]
Jan Kalina reassigned ELY-1494:
-------------------------------
Assignee: Jan Kalina
> SecurityException: JCE cannot authenticate the provider WildFlyElytron
> ----------------------------------------------------------------------
>
> Key: ELY-1494
> URL: https://issues.jboss.org/browse/ELY-1494
> Project: WildFly Elytron
> Issue Type: Bug
> Components: Testsuite
> Affects Versions: 1.2.0.Beta11
> Reporter: Martin Choma
> Assignee: Jan Kalina
>
> This happens on HP-UX in KeyStoreCredentialStoreTest. It probably related to ELY-1295 fix. Fix have to take HP-UX JDK in account as well.
>
> Btw. Isn't there more elegant way how to enable tests for PKCS12. Necessary hack seems to be problematic.
> {noformat}
> java.lang.SecurityException: JCE cannot authenticate the provider WildFlyElytron
> at javax.crypto.JceSecurity.getInstance(JceSecurity.java:118)
> at javax.crypto.SecretKeyFactory.getInstance(SecretKeyFactory.java:244)
> at org.wildfly.security.credential.store.impl.KeyStoreCredentialStoreTest.installWildFlyElytronProvider(KeyStoreCredentialStoreTest.java:117)
> Caused by: java.lang.SecurityException: Cannot verify jar:file:/hudson_workspace/workspace/wildfly-elytron-unit-tests/8cc93d85/wildfly-elytron/target/classes/!/
> at javax.crypto.JarVerifier.verifySingleJar(JarVerifier.java:448)
> at javax.crypto.JarVerifier.verifyJars(JarVerifier.java:363)
> at javax.crypto.JarVerifier.verify(JarVerifier.java:289)
> at javax.crypto.JceSecurity.verifyProviderJar(JceSecurity.java:164)
> at javax.crypto.JceSecurity.getVerificationResult(JceSecurity.java:190)
> at javax.crypto.JceSecurity.getInstance(JceSecurity.java:114)
> ... 2 more
> Caused by: java.security.PrivilegedActionException: java.io.FileNotFoundException: /hudson_workspace/workspace/wildfly-elytron-unit-tests/8cc93d85/wildfly-elytron/target/classes (Is a directory)
> at java.security.AccessController.doPrivileged(Native Method)
> at javax.crypto.JarVerifier.verifySingleJar(JarVerifier.java:426)
> ... 7 more
> Caused by: java.io.FileNotFoundException: /hudson_workspace/workspace/wildfly-elytron-unit-tests/8cc93d85/wildfly-elytron/target/classes (Is a directory)
> at java.util.zip.ZipFile.open(Native Method)
> at java.util.zip.ZipFile.<init>(ZipFile.java:225)
> at java.util.zip.ZipFile.<init>(ZipFile.java:155)
> at java.util.jar.JarFile.<init>(JarFile.java:166)
> at java.util.jar.JarFile.<init>(JarFile.java:103)
> at javax.crypto.JarVerifier$2.run(JarVerifier.java:440)
> at javax.crypto.JarVerifier$2.run(JarVerifier.java:427)
> ... 9 more
> {noformat}
> [1] https://jenkins.hosts.mwqe.eng.bos.redhat.com/hudson/view/EAP7/view/EAP7-...
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 3 months
[JBoss JIRA] (WFCORE-3450) CLI - avoid required attributes to be hard to see when using tab completion
by Ingo Weiss (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3450?page=com.atlassian.jira.plugi... ]
Ingo Weiss reassigned WFCORE-3450:
----------------------------------
Assignee: Ingo Weiss (was: Jean-Francois Denise)
> CLI - avoid required attributes to be hard to see when using tab completion
> ----------------------------------------------------------------------------
>
> Key: WFCORE-3450
> URL: https://issues.jboss.org/browse/WFCORE-3450
> Project: WildFly Core
> Issue Type: Feature Request
> Components: CLI
> Reporter: Miroslav Novak
> Assignee: Ingo Weiss
>
> This is follow up for WFCORE-2283 which marked required attributes by "*" when using tab completion. Still if there are many attributes, it's hard to see all required attributes, for example in:
> {code}
> [standalone@localhost:9990 /] /subsystem=messaging-activemq/server=default/cluster-connection=my-cluster:add(
> ! check-period connector-name* max-retry-interval notification-interval retry-interval-multiplier
> allow-direct-connections-only cluster-connection-address* discovery-group* message-load-balancing-type producer-window-size static-connectors*
> call-failover-timeout confirmation-window-size initial-connect-attempts min-large-message-size reconnect-attempts use-duplicate-detection
> call-timeout connection-ttl max-hops notification-attempts retry-interval
> {code}
> it's not clear at the first look how many required attributes there are.
> Suggestion is to group required attributes together and then provide list of other attributes, for example on the next line. Another options might be considered as well. For example to show required attributes when double pressing <tab>.
> Discussed on https://developer.jboss.org/wiki/CLI-BetterCompletionForArguments?et=watc...
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 3 months