[JBoss JIRA] (DROOLS-1271) CepEspTest.testEventWithShortExpiration() needs another fireAllRules to flush the Propagation Queue
by Tibor Zimányi (JIRA)
Tibor Zimányi created DROOLS-1271:
-------------------------------------
Summary: CepEspTest.testEventWithShortExpiration() needs another fireAllRules to flush the Propagation Queue
Key: DROOLS-1271
URL: https://issues.jboss.org/browse/DROOLS-1271
Project: Drools
Issue Type: Enhancement
Components: core engine
Reporter: Tibor Zimányi
Assignee: Mario Fusco
Priority: Minor
Test CepEspTest.testEventWithShortExpiration sometimes fails, but it's a false positive. There's a race condition in the test between fireAllRules, which flushes PropagationQueue, and timer job that puts event expiration action into PropagationQueue. So other fireAllRules is needed in the test that will flush the queue again so we test that all expired objects are removed from the engine.
I will make a PR for this.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years
[JBoss JIRA] (WFLY-6656) add-user.sh does not return the secret value in non-interactive mode.
by Ivo Hrádek (JIRA)
[ https://issues.jboss.org/browse/WFLY-6656?page=com.atlassian.jira.plugin.... ]
Ivo Hrádek commented on WFLY-6656:
----------------------------------
Hi [~ppetrou], are you working on this?
The secret value is just user's password encoded in base64, so probably you don't want to show this value on the output every time. So, I think displaying this value should be optional as in case of interactive mode.
Meanwhile, I have implemented a simple flag "--secret" or "-sv" and made a PR [1], with following behavior:
- If it was provided in non-interactive mode, the secret value would be printed, otherwise no,
- If it was provided in interactive mode, the secret value would be printed, without prompting for "yes/no",
- If it was provided in non-interactive mode together with "--silent" option, it wouldn't be printed.
btw: I think this JIRA should be more suitable for WFCORE.
--
[1] https://github.com/wildfly/wildfly-core/pull/1771
> add-user.sh does not return the secret value in non-interactive mode.
> ---------------------------------------------------------------------
>
> Key: WFLY-6656
> URL: https://issues.jboss.org/browse/WFLY-6656
> Project: WildFly
> Issue Type: Feature Request
> Components: Security
> Affects Versions: 10.0.0.Final
> Reporter: Petros Petrou
> Priority: Minor
> Fix For: Awaiting Volunteers
>
>
> Running add-user.sh in non-interactive mode does not return the secret value of the password. It would be a useful feature when automating user creation using platform build software.
> Non-Interactive Mode
> =============
> add-user.sh --user domainuser --password welcome1!
> Added user 'domainuser' to file '\opt\wildfly-10.0.0\standalone\configuration\mgmt-users.properties'
> Added user 'domainuser' to file '\opt\wildfly-10.0.0.Final\domain\configuration\mgmt-users.properties'
> Press any key to continue . . .
> Interactive Mode
> =============
> What type of user do you wish to add?
> a) Management User (mgmt-users.properties)
> b) Application User (application-users.properties)
> (a): a
> Enter the details of the new user to add.
> Using realm 'ManagementRealm' as discovered from the existing property files.
> Username : ppetrou
> Password recommendations are listed below. To modify these restrictions edit the add-user.properties configuration file.
> - The password should be different from the username
> - The password should not be one of the following restricted values {root, admin, administrator}
> - The password should contain at least 8 characters, 1 alphabetic character(s), 1 digit(s), 1 non-alphanumeric symbol(s)
> Password :
> Re-enter Password :
> What groups do you want this user to belong to? (Please enter a comma separated list, or leave blank for none)[ ]:
> About to add user 'ppetrou' for realm 'ManagementRealm'
> Is this correct yes/no? yes
> Added user 'ppetrou' to file '\opt\wildfly-10.0.0.Final\standalone\configuration\mgmt-users.properties'
> Added user 'ppetrou' to file '\opt\wildfly-10.0.0.Final\domain\configuration\mgmt-users.properties'
> Added user 'ppetrou' with groups to file '\opt\wildfly-10.0.0.Final\standalone\configuration\mgmt-groups.properties'
> Added user 'ppetrou' with groups to file '\opt\wildfly-10.0.0.Final\domain\configuration\mgmt-groups.properties'
> Is this new user going to be used for one AS process to connect to another AS process?
> e.g. for a slave host controller connecting to the master or for a Remoting connection for server to server EJB calls.
> yes/no? yes
> To represent the user add the following to the server-identities definition <secret value="d2VsY29tZTEh" />
> Press any key to continue . . .
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years
[JBoss JIRA] (WFLY-6173) Classes not unloaded after undeployment
by Martin Kouba (JIRA)
[ https://issues.jboss.org/browse/WFLY-6173?page=com.atlassian.jira.plugin.... ]
Martin Kouba commented on WFLY-6173:
------------------------------------
[~joeydaowang] Thanks for report. It looks like the next issue completely unrelated to CDI/Weld subsystem. My colleague Tomas Remes created JBEAP-5854.
> Classes not unloaded after undeployment
> ---------------------------------------
>
> Key: WFLY-6173
> URL: https://issues.jboss.org/browse/WFLY-6173
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld
> Affects Versions: 8.2.0.Final, 10.0.0.Final
> Reporter: Joey Wang
> Assignee: Martin Kouba
> Priority: Blocker
> Attachments: memory-leak.zip, memory-leak_New.zip
>
>
> I deployed a small web application with one single JSF and one managed bean, accessed the page and then undeployed the application. I found the classes of this application had never been unloaded via monitoring with Java VistualVM, also using '-XX:+TraceClassUnloading' JVM option proved the classes not unloaded.
> Then checking the heap dump of it, I found there were instance for each enum item (the managed bean has one enum type field, which is always initialized when the managed bean constructed) and one array instance including these enum instances.
> Please refer to the attachment for the same application. I started to verify the classloader memory leak issue because we found hot redeployment of our real application swallow some memory each time, then after lots of redeployment the server was short of memories.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years
[JBoss JIRA] (WFCORE-1758) WFLYCC0034: Closing leaked controller client
by Martin Choma (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1758?page=com.atlassian.jira.plugi... ]
Martin Choma edited comment on WFCORE-1758 at 9/2/16 4:04 AM:
--------------------------------------------------------------
I understand that it is very delicately piece of code. So most importantly potential change shouldn't break anything else. If you will decide, that finalize method can be enhanced, note, there are couple of others finalize() implementation with custom logic in wildfly core, which could be checked.
DeploymentPlanImpl
RemotingModelControllerClient
ConnectionImpl
MountHandle
Errors caused by implemented finalize() method occur probably very very rarely. So users probably can't reproduce it - hence doesn't report it.
was (Author: mchoma):
I understand that it is very delicately piece of code. So most importantly pottential change shouldn't break anything else. If you will decide, that finalize method can be enhanced, note, there are couple of others finalize() implementation with custom logic in wildfly core, which could be checked.
DeploymentPlanImpl
RemotingModelControllerClient
ConnectionImpl
MountHandle
Errors caused by implemented finalize() method occur probably very very rarely. So users probably can't reproduce it - hence doesn't report it.
> WFLYCC0034: Closing leaked controller client
> --------------------------------------------
>
> Key: WFCORE-1758
> URL: https://issues.jboss.org/browse/WFCORE-1758
> Project: WildFly Core
> Issue Type: Bug
> Reporter: Martin Choma
> Assignee: James Perkins
> Attachments: server.log
>
>
> We are intermittently getting "WFLYCC0034: Closing leaked controller client" from RemotingModelControllerClient#finalize method.
> I wonder, isn't implementation of RemotingModelControllerClient#finalize() method [1] example of dangerous "safety net" implementation discussed in presentation "JVM finalize pitfalls" [2] ?
> *Reproducer:*
> 1. using ibm java 1.8
> 2. setting <startup-timeout>1</startup-timeout>
> [1] https://github.com/wildfly/wildfly-core/blob/master/controller-client/src...
> [2] https://www.youtube.com/watch?v=UrGP6pfb0H8
> [3]
> {noformat}
> 05:54:10 Aug 16, 2016 5:54:10 AM org.jboss.as.controller.client.impl.RemotingModelControllerClient finalize
> 05:54:10 WARN: WFLYCC0034: Closing leaked controller client
> 05:54:10 WFLYCC0030: Allocation stack trace:
> 05:54:10 at java.lang.Thread.getStackTrace(Thread.java:1552)
> 05:54:10 at org.jboss.as.controller.client.impl.RemotingModelControllerClient.<init>(RemotingModelControllerClient.java:74)
> 05:54:10 at org.jboss.as.controller.client.ModelControllerClient$Factory.create(ModelControllerClient.java:567)
> 05:54:10 at org.wildfly.plugin.common.ManagementClient.<init>(ManagementClient.java:37)
> 05:54:10 at org.wildfly.plugin.common.AbstractServerConnection.createClient(AbstractServerConnection.java:126)
> 05:54:10 at org.wildfly.plugin.server.StartMojo.execute(StartMojo.java:269)
> 05:54:10 at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:132)
> 05:54:10 at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
> 05:54:10 at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
> 05:54:10 at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
> 05:54:10 at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:116)
> 05:54:10 at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:80)
> 05:54:10 at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
> 05:54:10 at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:120)
> 05:54:10 at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:355)
> 05:54:10 at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:155)
> 05:54:10 at org.apache.maven.cli.MavenCli.execute(MavenCli.java:584)
> 05:54:10 at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:216)
> 05:54:10 at org.apache.maven.cli.MavenCli.main(MavenCli.java:160)
> 05:54:10 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 05:54:10 at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> 05:54:10 at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 05:54:10 at java.lang.reflect.Method.invoke(Method.java:498)
> 05:54:10 at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
> 05:54:10 at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
> 05:54:10 at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
> 05:54:10 at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years
[JBoss JIRA] (DROOLS-1270) support fact handle operations for REST APIs on kie server
by Dan Cimpoesu (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1270?page=com.atlassian.jira.plugi... ]
Dan Cimpoesu updated DROOLS-1270:
---------------------------------
Labels: (was: kie)
> support fact handle operations for REST APIs on kie server
> ----------------------------------------------------------
>
> Key: DROOLS-1270
> URL: https://issues.jboss.org/browse/DROOLS-1270
> Project: Drools
> Issue Type: Enhancement
> Components: kie server
> Affects Versions: 6.5.0.CR1
> Environment: kie server
> Reporter: Dan Cimpoesu
> Assignee: Edson Tirelli
> Fix For: 6.5.0.Final
>
>
> Please support fact handle operations for REST APIs on kie server.
> Fact handle operations are currently not supported in kie server as they usually bring less value in rule based systems where most of the operations are stateless. Though they do provide rather big value for processes integrated with rules.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years
[JBoss JIRA] (DROOLS-1270) support fact handle operations for REST APIs on kie server
by Dan Cimpoesu (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1270?page=com.atlassian.jira.plugi... ]
Dan Cimpoesu updated DROOLS-1270:
---------------------------------
Labels: kie (was: )
> support fact handle operations for REST APIs on kie server
> ----------------------------------------------------------
>
> Key: DROOLS-1270
> URL: https://issues.jboss.org/browse/DROOLS-1270
> Project: Drools
> Issue Type: Enhancement
> Components: kie server
> Affects Versions: 6.5.0.CR1
> Environment: kie server
> Reporter: Dan Cimpoesu
> Assignee: Edson Tirelli
> Labels: kie
> Fix For: 6.5.0.Final
>
>
> Please support fact handle operations for REST APIs on kie server.
> Fact handle operations are currently not supported in kie server as they usually bring less value in rule based systems where most of the operations are stateless. Though they do provide rather big value for processes integrated with rules.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years
[JBoss JIRA] (DROOLS-1270) support fact handle operations for REST APIs on kie server
by Dan Cimpoesu (JIRA)
Dan Cimpoesu created DROOLS-1270:
------------------------------------
Summary: support fact handle operations for REST APIs on kie server
Key: DROOLS-1270
URL: https://issues.jboss.org/browse/DROOLS-1270
Project: Drools
Issue Type: Enhancement
Components: kie server
Affects Versions: 6.5.0.CR1
Environment: kie server
Reporter: Dan Cimpoesu
Assignee: Edson Tirelli
Fix For: 6.5.0.Final
Please support fact handle operations for REST APIs on kie server.
Fact handle operations are currently not supported in kie server as they usually bring less value in rule based systems where most of the operations are stateless. Though they do provide rather big value for processes integrated with rules.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years
[JBoss JIRA] (WFCORE-1758) WFLYCC0034: Closing leaked controller client
by Martin Choma (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1758?page=com.atlassian.jira.plugi... ]
Martin Choma commented on WFCORE-1758:
--------------------------------------
I understand that it is very delicately piece of code. So most importantly pottential change shouldn't break anything else. If you will decide, that finalize method can be enhanced, note, there are couple of others finalize() implementation with custom logic in wildfly core, which could be checked.
DeploymentPlanImpl
RemotingModelControllerClient
ConnectionImpl
MountHandle
Errors caused by implemented finalize() method occur probably very very rarely. So users probably can't reproduce it - hence doesn't report it.
> WFLYCC0034: Closing leaked controller client
> --------------------------------------------
>
> Key: WFCORE-1758
> URL: https://issues.jboss.org/browse/WFCORE-1758
> Project: WildFly Core
> Issue Type: Bug
> Reporter: Martin Choma
> Assignee: James Perkins
> Attachments: server.log
>
>
> We are intermittently getting "WFLYCC0034: Closing leaked controller client" from RemotingModelControllerClient#finalize method.
> I wonder, isn't implementation of RemotingModelControllerClient#finalize() method [1] example of dangerous "safety net" implementation discussed in presentation "JVM finalize pitfalls" [2] ?
> *Reproducer:*
> 1. using ibm java 1.8
> 2. setting <startup-timeout>1</startup-timeout>
> [1] https://github.com/wildfly/wildfly-core/blob/master/controller-client/src...
> [2] https://www.youtube.com/watch?v=UrGP6pfb0H8
> [3]
> {noformat}
> 05:54:10 Aug 16, 2016 5:54:10 AM org.jboss.as.controller.client.impl.RemotingModelControllerClient finalize
> 05:54:10 WARN: WFLYCC0034: Closing leaked controller client
> 05:54:10 WFLYCC0030: Allocation stack trace:
> 05:54:10 at java.lang.Thread.getStackTrace(Thread.java:1552)
> 05:54:10 at org.jboss.as.controller.client.impl.RemotingModelControllerClient.<init>(RemotingModelControllerClient.java:74)
> 05:54:10 at org.jboss.as.controller.client.ModelControllerClient$Factory.create(ModelControllerClient.java:567)
> 05:54:10 at org.wildfly.plugin.common.ManagementClient.<init>(ManagementClient.java:37)
> 05:54:10 at org.wildfly.plugin.common.AbstractServerConnection.createClient(AbstractServerConnection.java:126)
> 05:54:10 at org.wildfly.plugin.server.StartMojo.execute(StartMojo.java:269)
> 05:54:10 at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:132)
> 05:54:10 at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
> 05:54:10 at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
> 05:54:10 at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
> 05:54:10 at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:116)
> 05:54:10 at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:80)
> 05:54:10 at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
> 05:54:10 at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:120)
> 05:54:10 at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:355)
> 05:54:10 at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:155)
> 05:54:10 at org.apache.maven.cli.MavenCli.execute(MavenCli.java:584)
> 05:54:10 at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:216)
> 05:54:10 at org.apache.maven.cli.MavenCli.main(MavenCli.java:160)
> 05:54:10 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 05:54:10 at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> 05:54:10 at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 05:54:10 at java.lang.reflect.Method.invoke(Method.java:498)
> 05:54:10 at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
> 05:54:10 at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
> 05:54:10 at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
> 05:54:10 at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years
[JBoss JIRA] (DROOLS-1269) RHQ / JON plug-in display wrong hierarchy and repeatedly nesting KieSession under KieBase
by Matteo Mortari (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1269?page=com.atlassian.jira.plugi... ]
Matteo Mortari updated DROOLS-1269:
-----------------------------------
Description:
... regardless of the real KieBase they actually belong to.
Ref example screenshot:
!rhqjon.png|thumbnail!
was:
... regardless of the real KieBase they actually belong to.
Ref example screenshot:
!rhqjon.png!
> RHQ / JON plug-in display wrong hierarchy and repeatedly nesting KieSession under KieBase
> -----------------------------------------------------------------------------------------
>
> Key: DROOLS-1269
> URL: https://issues.jboss.org/browse/DROOLS-1269
> Project: Drools
> Issue Type: Bug
> Components: integration
> Affects Versions: 6.1.0.Final, 6.2.0.Final, 6.3.0.Final, 6.4.0.Final
> Reporter: Matteo Mortari
> Assignee: Matteo Mortari
> Priority: Minor
> Attachments: rhqjon.png
>
>
> ... regardless of the real KieBase they actually belong to.
> Ref example screenshot:
> !rhqjon.png|thumbnail!
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years