[JBoss JIRA] (DROOLS-5095) [DMN Designer] Investigate performance switching between editor instances
by Michael Biarnes Kiefer (Jira)
[ https://issues.redhat.com/browse/DROOLS-5095?page=com.atlassian.jira.plug... ]
Michael Biarnes Kiefer updated DROOLS-5095:
-------------------------------------------
Fix Version/s: 7.43.0.Final
(was: 7.42.0.Final)
> [DMN Designer] Investigate performance switching between editor instances
> -------------------------------------------------------------------------
>
> Key: DROOLS-5095
> URL: https://issues.redhat.com/browse/DROOLS-5095
> Project: Drools
> Issue Type: Task
> Components: DMN Editor
> Affects Versions: 7.33.0.Final
> Reporter: Jozef Marko
> Assignee: Guilherme Gomes
> Priority: Minor
> Labels: drools-tools
> Fix For: 7.43.0.Final
>
> Attachments: switch-dmn.webm
>
>
> This JIRA is to investigate the reported performance issue switching between different DMN Designer instances in Business Central.
> The issue was noticed by [~jomarko] when testing DROOLS-5058 (although the fix therein should have had *zero* affect on switching).
> For more details see the video [^switch-dmn.webm]
> h2. Manual acceptance test
> - Prepare 5 DMN models in project
> - Open all in parallel
> - Try to switch between them, keep all opened
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 11 months
[JBoss JIRA] (WFLY-13770) Create jdbc job repository using deployment descriptors
by Jurij Bernhardt (Jira)
[ https://issues.redhat.com/browse/WFLY-13770?page=com.atlassian.jira.plugi... ]
Jurij Bernhardt updated WFLY-13770:
-----------------------------------
Description:
The Example for "new Job Repository" ([https://docs.wildfly.org/20/Admin_Guide.html#deployment-descriptors]) doesn't work properly.
<jboss xmlns="urn:jboss:1.0">
<batch xmlns="urn:jboss:batch-jberet:1.0">
<job-repository>
<jdbc jndi-name="java:jboss/datasources/ExampleDS"/>
</job-repository>
</batch>
</jboss>
Schema batch-jberet_1_0.xsd alllows only in-memory or named job-repositoryType.
You get the validation exception by using the jdbc example.
It would be useful to improve the batch-jberet integration so that the example given above would work.
was:
The Example for "new Job Repository" ([https://docs.wildfly.org/20/Admin_Guide.html#deployment-descriptors]) doesn't work properly.
<jboss xmlns="urn:jboss:1.0">
<batch xmlns="urn:jboss:batch-jberet:1.0">
<job-repository>
<jdbc jndi-name="java:jboss/datasources/ExampleDS"/>
</job-repository>
</batch>
</jboss>
Schema batch-jberet_1_0.xsd alllow only in-memory or named job-repositoryType.
You get the validation exception by using the jdbc example.
It would be useful to improve the batch-jberet integration so that the example given above would work.
> Create jdbc job repository using deployment descriptors
> -------------------------------------------------------
>
> Key: WFLY-13770
> URL: https://issues.redhat.com/browse/WFLY-13770
> Project: WildFly
> Issue Type: Enhancement
> Components: Batch
> Affects Versions: 20.0.1.Final
> Reporter: Jurij Bernhardt
> Assignee: Cheng Fang
> Priority: Major
>
> The Example for "new Job Repository" ([https://docs.wildfly.org/20/Admin_Guide.html#deployment-descriptors]) doesn't work properly.
> <jboss xmlns="urn:jboss:1.0">
> <batch xmlns="urn:jboss:batch-jberet:1.0">
> <job-repository>
> <jdbc jndi-name="java:jboss/datasources/ExampleDS"/>
> </job-repository>
> </batch>
> </jboss>
> Schema batch-jberet_1_0.xsd alllows only in-memory or named job-repositoryType.
> You get the validation exception by using the jdbc example.
> It would be useful to improve the batch-jberet integration so that the example given above would work.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 11 months
[JBoss JIRA] (WFLY-13770) Create jdbc job repository using deployment descriptors
by Jurij Bernhardt (Jira)
Jurij Bernhardt created WFLY-13770:
--------------------------------------
Summary: Create jdbc job repository using deployment descriptors
Key: WFLY-13770
URL: https://issues.redhat.com/browse/WFLY-13770
Project: WildFly
Issue Type: Enhancement
Components: Batch
Affects Versions: 20.0.1.Final
Reporter: Jurij Bernhardt
Assignee: Cheng Fang
The Example for "new Job Repository" ([https://docs.wildfly.org/20/Admin_Guide.html#deployment-descriptors]) doesn't work properly.
<jboss xmlns="urn:jboss:1.0">
<batch xmlns="urn:jboss:batch-jberet:1.0">
<job-repository>
<jdbc jndi-name="java:jboss/datasources/ExampleDS"/>
</job-repository>
</batch>
</jboss>
Schema batch-jberet_1_0.xsd alllow only in-memory or named job-repositoryType.
You get the validation exception by using the jdbc example.
It would be useful to improve the batch-jberet integration so that the example given above would work.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 11 months
[JBoss JIRA] (DROOLS-5574) User can not work with project
by Enrique González Martínez (Jira)
[ https://issues.redhat.com/browse/DROOLS-5574?page=com.atlassian.jira.plug... ]
Enrique González Martínez closed DROOLS-5574.
---------------------------------------------
Resolution: Done
already reverted
> User can not work with project
> ------------------------------
>
> Key: DROOLS-5574
> URL: https://issues.redhat.com/browse/DROOLS-5574
> Project: Drools
> Issue Type: Bug
> Components: Examples (Workbench)
> Affects Versions: 7.42.0.Final
> Reporter: Jozef Marko
> Assignee: Enrique González Martínez
> Priority: Blocker
> Labels: Regression
> Attachments: Screenshot from 2020-08-12 15-57-43.png, error.log
>
>
> The issue is after user import sample project and tries to open an Asset, multiple errors appear in server log and the UI is not responsive.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 11 months
[JBoss JIRA] (ELY-1700) Intermittently failing AttributeMappingSuiteChild
by Farah Juma (Jira)
[ https://issues.redhat.com/browse/ELY-1700?page=com.atlassian.jira.plugin.... ]
Farah Juma updated ELY-1700:
----------------------------
Fix Version/s: 1.13.0.CR5
(was: 1.13.0.CR4)
> Intermittently failing AttributeMappingSuiteChild
> -------------------------------------------------
>
> Key: ELY-1700
> URL: https://issues.redhat.com/browse/ELY-1700
> Project: WildFly Elytron
> Issue Type: Bug
> Components: Testsuite
> Affects Versions: 1.7.0.CR2
> Reporter: Martin Choma
> Priority: Minor
> Fix For: 1.13.0.CR5
>
>
> With ration 1:1000 we see ELY01125: Ldap-backed realm failed to obtain context.
> {noformat}
> org.wildfly.security.auth.server.RealmUnavailableException: ELY01125: Ldap-backed realm failed to obtain context
> at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm.obtainContext(LdapSecurityRealm.java:215)
> at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm.access$600(LdapSecurityRealm.java:102)
> at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm$LdapRealmIdentity.exists(LdapSecurityRealm.java:622)
> at org.wildfly.security.auth.server.ServerAuthenticationContext.exists(ServerAuthenticationContext.java:447)
> at org.wildfly.security.ldap.AbstractAttributeMappingSuiteChild.assertAttributes(AbstractAttributeMappingSuiteChild.java:85)
> at org.wildfly.security.ldap.AbstractAttributeMappingSuiteChild.assertAttributes(AbstractAttributeMappingSuiteChild.java:77)
> at org.wildfly.security.ldap.AttributeMappingSuiteChild.testSingleAttributeToSpecifiedName(AttributeMappingSuiteChild.java:33)
> at org.wildfly.security.ldap.DirContextFactoryRule$1.evaluate(DirContextFactoryRule.java:218)
> Caused by: javax.naming.NamingException: LDAP response read timed out, timeout used:5000ms.
> at com.sun.jndi.ldap.Connection.readReply(Connection.java:507)
> at com.sun.jndi.ldap.LdapClient.ldapBind(LdapClient.java:365)
> at com.sun.jndi.ldap.LdapClient.authenticate(LdapClient.java:214)
> at com.sun.jndi.ldap.LdapCtx.connect(LdapCtx.java:2791)
> at com.sun.jndi.ldap.LdapCtx.<init>(LdapCtx.java:319)
> at com.sun.jndi.ldap.LdapCtxFactory.getUsingURL(LdapCtxFactory.java:192)
> at com.sun.jndi.ldap.LdapCtxFactory.getUsingURLs(LdapCtxFactory.java:210)
> at com.sun.jndi.ldap.LdapCtxFactory.getLdapCtxInstance(LdapCtxFactory.java:153)
> at com.sun.jndi.ldap.LdapCtxFactory.getInitialContext(LdapCtxFactory.java:83)
> at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:684)
> at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:313)
> at javax.naming.InitialContext.init(InitialContext.java:244)
> at javax.naming.ldap.InitialLdapContext.<init>(InitialLdapContext.java:154)
> at org.wildfly.security.auth.realm.ldap.SimpleDirContextFactoryBuilder$SimpleDirContextFactory.createDirContext(SimpleDirContextFactoryBuilder.java:436)
> at org.wildfly.security.auth.realm.ldap.SimpleDirContextFactoryBuilder$SimpleDirContextFactory.obtainDirContext(SimpleDirContextFactoryBuilder.java:355)
> at org.wildfly.security.ldap.DirContextFactoryRule.lambda$create$0(DirContextFactoryRule.java:258)
> at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm.obtainContext(LdapSecurityRealm.java:203)
> ... 7 more
> {noformat}
> {noformat}
> 00:29:39,451 TRACE (main) [org.wildfly.security] <SecurityDomain.java:1036> Building security domain with defaultRealmName default.
> 00:29:39,452 TRACE (main) [org.wildfly.security] <SecurityDomain.java:708> Role mapping: principal [anonymous] -> decoded roles [] -> realm mapped roles [] -> domain mapped roles []
> 00:29:39,452 TRACE (main) [org.wildfly.security] <ServerAuthenticationContext.java:1163> Principal assigning: [userWithAttributes], pre-realm rewritten: [userWithAttributes], realm name: [default], post-realm rewritten: [userWithAttributes], realm rewritten: [userWithAttributes]
> 00:29:39,453 DEBUG (main) [org.wildfly.security] <LdapSecurityRealm.java:189> Obtaining lock for identity [userWithAttributes]...
> 00:29:39,454 DEBUG (main) [org.wildfly.security] <LdapSecurityRealm.java:197> Obtained lock for identity [userWithAttributes].
> 00:29:39,454 DEBUG (main) [org.wildfly.security] <SimpleDirContextFactoryBuilder.java:427> Creating [class javax.naming.directory.InitialDirContext] with environment:
> 00:29:39,454 DEBUG (main) [org.wildfly.security] <SimpleDirContextFactoryBuilder.java:428> Property [java.naming.security.credentials] with value [******]
> 00:29:39,455 DEBUG (main) [org.wildfly.security] <SimpleDirContextFactoryBuilder.java:428> Property [java.naming.ldap.factory.socket] with value [org.wildfly.security.auth.realm.ldap.ThreadLocalSSLSocketFactory]
> 00:29:39,455 DEBUG (main) [org.wildfly.security] <SimpleDirContextFactoryBuilder.java:428> Property [java.naming.security.authentication] with value [simple]
> 00:29:39,456 DEBUG (main) [org.wildfly.security] <SimpleDirContextFactoryBuilder.java:428> Property [java.naming.provider.url] with value [ldap://localhost:11390/]
> 00:29:39,456 DEBUG (main) [org.wildfly.security] <SimpleDirContextFactoryBuilder.java:428> Property [com.sun.jndi.ldap.read.timeout] with value [60000]
> 00:29:39,456 DEBUG (main) [org.wildfly.security] <SimpleDirContextFactoryBuilder.java:428> Property [com.sun.jndi.ldap.connect.timeout] with value [5000]
> 00:29:39,456 DEBUG (main) [org.wildfly.security] <SimpleDirContextFactoryBuilder.java:428> Property [java.naming.security.principal] with value [uid=server,dc=elytron,dc=wildfly,dc=org]
> 00:29:39,457 DEBUG (main) [org.wildfly.security] <SimpleDirContextFactoryBuilder.java:428> Property [java.naming.referral] with value [ignore]
> 00:29:39,457 DEBUG (main) [org.wildfly.security] <SimpleDirContextFactoryBuilder.java:428> Property [java.naming.factory.initial] with value [com.sun.jndi.ldap.LdapCtxFactory]
> 00:29:44,528 DEBUG (main) [org.wildfly.security] <SimpleDirContextFactoryBuilder.java:438> Could not create [class javax.naming.ldap.InitialLdapContext]. Failed to connect to LDAP server.: javax.naming.NamingException: LDAP response read timed out, timeout used:5000ms.
> at com.sun.jndi.ldap.Connection.readReply(Connection.java:507)
> at com.sun.jndi.ldap.LdapClient.ldapBind(LdapClient.java:365)
> at com.sun.jndi.ldap.LdapClient.authenticate(LdapClient.java:214)
> at com.sun.jndi.ldap.LdapCtx.connect(LdapCtx.java:2791)
> at com.sun.jndi.ldap.LdapCtx.<init>(LdapCtx.java:319)
> at com.sun.jndi.ldap.LdapCtxFactory.getUsingURL(LdapCtxFactory.java:192)
> at com.sun.jndi.ldap.LdapCtxFactory.getUsingURLs(LdapCtxFactory.java:210)
> at com.sun.jndi.ldap.LdapCtxFactory.getLdapCtxInstance(LdapCtxFactory.java:153)
> at com.sun.jndi.ldap.LdapCtxFactory.getInitialContext(LdapCtxFactory.java:83)
> at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:684)
> at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:313)
> at javax.naming.InitialContext.init(InitialContext.java:244)
> at javax.naming.ldap.InitialLdapContext.<init>(InitialLdapContext.java:154)
> at org.wildfly.security.auth.realm.ldap.SimpleDirContextFactoryBuilder$SimpleDirContextFactory.createDirContext(SimpleDirContextFactoryBuilder.java:436)
> at org.wildfly.security.auth.realm.ldap.SimpleDirContextFactoryBuilder$SimpleDirContextFactory.obtainDirContext(SimpleDirContextFactoryBuilder.java:355)
> at org.wildfly.security.ldap.DirContextFactoryRule.lambda$create$0(DirContextFactoryRule.java:258)
> at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm.obtainContext(LdapSecurityRealm.java:203)
> at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm.access$600(LdapSecurityRealm.java:102)
> at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm$LdapRealmIdentity.exists(LdapSecurityRealm.java:622)
> at org.wildfly.security.auth.server.ServerAuthenticationContext.exists(ServerAuthenticationContext.java:447)
> at org.wildfly.security.ldap.AbstractAttributeMappingSuiteChild.assertAttributes(AbstractAttributeMappingSuiteChild.java:85)
> at org.wildfly.security.ldap.AbstractAttributeMappingSuiteChild.assertAttributes(AbstractAttributeMappingSuiteChild.java:77)
> at org.wildfly.security.ldap.AttributeMappingSuiteChild.testSingleAttributeToSpecifiedName(AttributeMappingSuiteChild.java:33)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> 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.executeTestMethod(JUnit4TestRunnerDecorator.java:162)
> at mockit.integration.junit4.internal.JUnit4TestRunnerDecorator.invokeExplosively(JUnit4TestRunnerDecorator.java:71)
> 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.InvokeMethod.evaluate(InvokeMethod.java:17)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> 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.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.wildfly.security.ldap.DirContextFactoryRule$1.evaluate(DirContextFactoryRule.java:218)
> at org.junit.rules.RunRules.evaluate(RunRules.java:20)
> 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)
> 00:29:44,529 INFO (pool-3-thread-2) [org.apache.directory.server.ldap.handlers.LdapRequestHandler] <LdapRequestHandler.java:131> ignoring the message Abandon Request :
> Message Id : 1org.apache.directory.api.ldap.model.message.AbandonRequestImpl@8444b052 received from null session
> {noformat}
> Maybe just to try prolong SimpleDirContextFactoryBuilder#DEFAULT_CONNECT_TIMEOUT [1]
> This issue occurs also with ELY-1699. It is very probable machine was slow. But it would be fine if testsuite could cope with this situation as well.
>
> [1] https://github.com/wildfly-security/wildfly-elytron/blob/38e1e01972414ad7...
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 11 months
[JBoss JIRA] (ELY-1682) Fallback to another SASL client mechanism when SASL client initialisation fails
by Farah Juma (Jira)
[ https://issues.redhat.com/browse/ELY-1682?page=com.atlassian.jira.plugin.... ]
Farah Juma updated ELY-1682:
----------------------------
Fix Version/s: 1.13.0.CR5
(was: 1.13.0.CR4)
> Fallback to another SASL client mechanism when SASL client initialisation fails
> -------------------------------------------------------------------------------
>
> Key: ELY-1682
> URL: https://issues.redhat.com/browse/ELY-1682
> Project: WildFly Elytron
> Issue Type: Bug
> Components: SASL
> Affects Versions: 1.7.0.CR1
> Reporter: Martin Choma
> Priority: Major
> Fix For: 1.13.0.CR5
>
> Attachments: org.jboss.eapqe.krbldap.eap71.tests.krb.ejb.KerberosEjbGssapiTestCase-output.txt
>
>
> {code:title=HipChat conversation}
> Martin Choma: I have got this situation here; Server is authenticated with GSSAPI and PLAIN. Client has only username/password credential - no kerberos credential.
> But client tries to create GssapiSaslClient as well (which make problem on IBM). Once I set .setSaslMechanismSelector(SaslMechanismSelector.fromString("PLAIN")) scenario works ok.
> I wonder could Authentication Client be smart enough to not try to initialize authentication mechanisms which it has not credentials for?
> Darran Lofthouse: Client side GSSAPI we tend not to have configured credentials as the mech obtains from OS level. The mech should fail and allow the next mech to be selected
> Martin Choma: Ok, so I will create issue. Seems on client side this mechanism fallback does not work properly. (At least in IBM JDK case).
> In this case it is initialization of mechanism which is failing, so maybe fallback does not have chance to get involved.
> Darran Lofthouse: Sounds possible, if a mech can not initialise we should likely treat it as a failed mech and move on - maybe something needed in Remoting
> though for that one as that is where that loop happens but start with an ELY issue
> {code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 11 months