[JBoss JIRA] (WFLY-3078) directory-grouping configuration is not getting persisted via CLI when no servers defined
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-3078?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-3078:
-----------------------------------------------
Paul Gier <pgier(a)redhat.com> changed the Status of [bug 1073715|https://bugzilla.redhat.com/show_bug.cgi?id=1073715] from MODIFIED to ON_QA
> directory-grouping configuration is not getting persisted via CLI when no servers defined
> -----------------------------------------------------------------------------------------
>
> Key: WFLY-3078
> URL: https://issues.jboss.org/browse/WFLY-3078
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Domain Management
> Affects Versions: 8.0.0.Final
> Environment: All Operating System
> Reporter: Jay Kumar SenSharma
> Assignee: Emanuel Muckenhuber
> Fix For: 8.0.1.Final
>
>
> - If none of the servers are defined in "host.xml" (means <servers></servers> empty tag is present) and if the user tries to run the following CLI command to change the "directory-grouping" to "by-type" then the value is not persisted in the configuration file (host.xml) and the <servers></servers> tag is also removed from the host.xml
> {code}
> /host=master/:write-attribute(name=directory-grouping,value=by-type)
> {code}
> - The value of "directory-grouping" is stored "in memory" so this change does not survive the host restart.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 10 months
[JBoss JIRA] (JBEE-151) Missing doPrivileged block(s) around getContextClassLoader
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/JBEE-151?page=com.atlassian.jira.plugin.s... ]
RH Bugzilla Integration updated JBEE-151:
-----------------------------------------
Bugzilla Update: Perform
Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1075045
> Missing doPrivileged block(s) around getContextClassLoader
> -----------------------------------------------------------
>
> Key: JBEE-151
> URL: https://issues.jboss.org/browse/JBEE-151
> Project: JBoss JavaEE Spec APIs
> Issue Type: Bug
> Components: general
> Reporter: Carlo de Wolf
> Assignee: Shelly McGowan
>
> jboss-el-api_2.2_spec-1.0.2.Final-redhat-1.jar:1.0.2.Final-redhat-1
> {code}
> 12:56:34,897 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[default-host].[/read-props].[jsp]] (http-/127.0.0.1:8080-4) JBWEB000236: Servlet.service() for servlet jsp threw exception: java.security.AccessControlException: access denied ("java.lang.RuntimePermission" "getClassLoader")
> at java.security.AccessControlContext.checkPermission(AccessControlContext.java:372) [rt.jar:1.7.0_45]
> at java.security.AccessController.checkPermission(AccessController.java:559) [rt.jar:1.7.0_45]
> at java.lang.SecurityManager.checkPermission(SecurityManager.java:549) [rt.jar:1.7.0_45]
> at java.lang.ClassLoader.checkClassLoaderPermission(ClassLoader.java:1561) [rt.jar:1.7.0_45]
> at java.lang.Thread.getContextClassLoader(Thread.java:1472) [rt.jar:1.7.0_45]
> at javax.el.FactoryFinder.find(FactoryFinder.java:130) [jboss-el-api_2.2_spec-1.0.2.Final-redhat-1.jar:1.0.2.Final-redhat-1]
> at javax.el.ExpressionFactory.newInstance(ExpressionFactory.java:185) [jboss-el-api_2.2_spec-1.0.2.Final-redhat-1.jar:1.0.2.Final-redhat-1]
> at javax.el.ExpressionFactory.newInstance(ExpressionFactory.java:156) [jboss-el-api_2.2_spec-1.0.2.Final-redhat-1.jar:1.0.2.Final-redhat-1]
> at org.apache.jasper.runtime.JspApplicationContextImpl.<init>(JspApplicationContextImpl.java:48) [jbossweb-7.4.0.Beta4.jar:7.4.0.Beta4]
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 10 months
[JBoss JIRA] (JBEE-151) Missing doPrivileged block(s) around getContextClassLoader
by Carlo de Wolf (JIRA)
Carlo de Wolf created JBEE-151:
----------------------------------
Summary: Missing doPrivileged block(s) around getContextClassLoader
Key: JBEE-151
URL: https://issues.jboss.org/browse/JBEE-151
Project: JBoss JavaEE Spec APIs
Issue Type: Bug
Components: general
Reporter: Carlo de Wolf
Assignee: Shelly McGowan
jboss-el-api_2.2_spec-1.0.2.Final-redhat-1.jar:1.0.2.Final-redhat-1
{code}
12:56:34,897 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[default-host].[/read-props].[jsp]] (http-/127.0.0.1:8080-4) JBWEB000236: Servlet.service() for servlet jsp threw exception: java.security.AccessControlException: access denied ("java.lang.RuntimePermission" "getClassLoader")
at java.security.AccessControlContext.checkPermission(AccessControlContext.java:372) [rt.jar:1.7.0_45]
at java.security.AccessController.checkPermission(AccessController.java:559) [rt.jar:1.7.0_45]
at java.lang.SecurityManager.checkPermission(SecurityManager.java:549) [rt.jar:1.7.0_45]
at java.lang.ClassLoader.checkClassLoaderPermission(ClassLoader.java:1561) [rt.jar:1.7.0_45]
at java.lang.Thread.getContextClassLoader(Thread.java:1472) [rt.jar:1.7.0_45]
at javax.el.FactoryFinder.find(FactoryFinder.java:130) [jboss-el-api_2.2_spec-1.0.2.Final-redhat-1.jar:1.0.2.Final-redhat-1]
at javax.el.ExpressionFactory.newInstance(ExpressionFactory.java:185) [jboss-el-api_2.2_spec-1.0.2.Final-redhat-1.jar:1.0.2.Final-redhat-1]
at javax.el.ExpressionFactory.newInstance(ExpressionFactory.java:156) [jboss-el-api_2.2_spec-1.0.2.Final-redhat-1.jar:1.0.2.Final-redhat-1]
at org.apache.jasper.runtime.JspApplicationContextImpl.<init>(JspApplicationContextImpl.java:48) [jbossweb-7.4.0.Beta4.jar:7.4.0.Beta4]
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 10 months
[JBoss JIRA] (JBASMP-58) jboss-as-maven-plugin freezes on authentication
by Bryan Galvin (JIRA)
[ https://issues.jboss.org/browse/JBASMP-58?page=com.atlassian.jira.plugin.... ]
Bryan Galvin commented on JBASMP-58:
------------------------------------
We upgraded to jboss-as-maven-plugin version=7.4.Final, today. We have not experienced the 'freeze' issue since the upgrade.
> jboss-as-maven-plugin freezes on authentication
> -----------------------------------------------
>
> Key: JBASMP-58
> URL: https://issues.jboss.org/browse/JBASMP-58
> Project: JBoss AS Maven Plugins
> Issue Type: Bug
> Components: deploy
> Affects Versions: 7.5.Final
> Environment: mac os x 10.8.5 & mac os x 10.9
> mvn 3.1.1
> Reporter: Julien Derveeuw
> Assignee: James Perkins
> Priority: Critical
>
> I have jboss 7.1.1 in standalone mode running on machine A (linux).
> I want to deploy remotely to it using client machine B @ mac os X 10.8.5 / JDK 1.7.0_45-b18.
> If I connect from B to A using {{jboss-cli}}, everything works fine, I am able to login.
> If I try to deploy from maven with this :
> {code:xml}
> <groupId>org.jboss.as.plugins</groupId>
> <artifactId>jboss-as-maven-plugin</artifactId>
> <version>7.5.Final</version>
> <configuration>
> <hostname>${deploy.jboss.host}</hostname>
> <port>${deploy.jboss.port}</port>
> <username>${deploy.jboss.user}</username>
> <password>${deploy.jboss.password}</password>
> </configuration>
> <executions>
> <execution>
> <phase>install</phase>
> <goals>
> <goal>deploy</goal>
> </goals>
> </execution>
> </executions>
> {code}
> plugin freezes indefinitely on
> {{Authenticating against security realm: ManagementRealm}}
> No more details are available with {{mvn -X}}
> If I remove the password or username from pom, it fails correctly with :
> {{The connection failed: Authentication failed: all available authentication mechanisms failed}}
> so it seems that the plugin somehow manages to connect to machine A.
> After digging on google, I ended up adding {{-Djava.nio.channels.spi.SelectorProvider=sun.nio.ch.KQueueSelectorProvider}} to mvn runner options because NIOs on jdk7@macosx is said to be buggy but it didn't help.
> More details :
> {code:title=mvn 3.1.1 output|borderStyle=solid}Nov 7, 2013 10:40:09 PM org.xnio.Xnio <clinit>
> INFO: XNIO Version 3.0.3.GA
> Nov 7, 2013 10:40:09 PM org.xnio.nio.NioXnio <clinit>
> INFO: XNIO NIO Implementation Version 3.0.3.GA
> Nov 7, 2013 10:40:09 PM org.jboss.remoting3.EndpointImpl <clinit>
> INFO: JBoss Remoting version 3.2.3.GA
> Authenticating against security realm: ManagementRealm
> {code}
> {code:title=jstack 7.1.1.Final|borderStyle=solid}
> "main" prio=5 tid=7f86d6800800 nid=0x1060f0000 in Object.wait() [1060ee000]
> java.lang.Thread.State: WAITING (on object monitor)
> at java.lang.Object.wait(Native Method)
> - waiting on <7f4102a20> (a org.jboss.as.protocol.mgmt.ActiveOperationSupport$ActiveOperationImpl)
> at java.lang.Object.wait(Object.java:485)
> at org.jboss.threads.AsyncFutureTask.await(AsyncFutureTask.java:192)
> - locked <7f4102a20> (a org.jboss.as.protocol.mgmt.ActiveOperationSupport$ActiveOperationImpl)
> at org.jboss.threads.AsyncFutureTask.get(AsyncFutureTask.java:266)
> - locked <7f4102a20> (a org.jboss.as.protocol.mgmt.ActiveOperationSupport$ActiveOperationImpl)
> at org.jboss.as.controller.client.impl.AbstractModelControllerClient$DelegatingCancellableAsyncFuture.get(AbstractModelControllerClient.java:363)
> at org.jboss.as.controller.client.impl.AbstractModelControllerClient$DelegatingCancellableAsyncFuture.get(AbstractModelControllerClient.java:317)
> at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeForResult(AbstractModelControllerClient.java:137)
> at org.jboss.as.controller.client.impl.AbstractModelControllerClient.execute(AbstractModelControllerClient.java:81)
> at org.jboss.as.plugin.deployment.standalone.StandaloneDeployment.exists(StandaloneDeployment.java:175)
> at org.jboss.as.plugin.deployment.standalone.StandaloneDeployment.createPlan(StandaloneDeployment.java:108)
> at org.jboss.as.plugin.deployment.standalone.StandaloneDeployment.execute(StandaloneDeployment.java:133)
> at org.jboss.as.plugin.deployment.AbstractDeployment.execute(AbstractDeployment.java:138)
> at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:106)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
> at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
> at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
> at org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
> at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:317)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:152)
> at org.apache.maven.cli.MavenCli.execute(MavenCli.java:555)
> at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:214)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:158)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
> at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
> at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
> {code}
> {code:title=jstack 7.5.Final|borderStyle=solid}
> "main" prio=5 tid=7fceea001000 nid=0x10d4d0000 in Object.wait() [10d4ce000]
> java.lang.Thread.State: WAITING (on object monitor)
> at java.lang.Object.wait(Native Method)
> - waiting on <7f42f2150> (a org.jboss.as.protocol.mgmt.ActiveOperationSupport$ActiveOperationImpl)
> at java.lang.Object.wait(Object.java:485)
> at org.jboss.threads.AsyncFutureTask.await(AsyncFutureTask.java:192)
> - locked <7f42f2150> (a org.jboss.as.protocol.mgmt.ActiveOperationSupport$ActiveOperationImpl)
> at org.jboss.threads.AsyncFutureTask.get(AsyncFutureTask.java:266)
> - locked <7f42f2150> (a org.jboss.as.protocol.mgmt.ActiveOperationSupport$ActiveOperationImpl)
> at org.jboss.as.controller.client.impl.AbstractDelegatingAsyncFuture.get(AbstractDelegatingAsyncFuture.java:100)
> at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeForResult(AbstractModelControllerClient.java:127)
> at org.jboss.as.controller.client.impl.AbstractModelControllerClient.execute(AbstractModelControllerClient.java:71)
> at org.jboss.as.plugin.common.AbstractServerConnection.isDomainServer(AbstractServerConnection.java:234)
> at org.jboss.as.plugin.common.AbstractServerConnection.getClient(AbstractServerConnection.java:156)
> - locked <7f42f2230> (a java.lang.Object)
> at org.jboss.as.plugin.common.AbstractServerConnection.isDomainServer(AbstractServerConnection.java:133)
> - locked <7f42f2230> (a java.lang.Object)
> at org.jboss.as.plugin.deployment.AbstractDeployment.validate(AbstractDeployment.java:192)
> at org.jboss.as.plugin.deployment.AbstractDeployment.doExecute(AbstractDeployment.java:136)
> - locked <7f42f2230> (a java.lang.Object)
> at org.jboss.as.plugin.deployment.AbstractAppDeployment.doExecute(AbstractAppDeployment.java:70)
> at org.jboss.as.plugin.deployment.AbstractDeployment.execute(AbstractDeployment.java:111)
> at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:106)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
> at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
> at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
> at org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
> at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:317)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:152)
> at org.apache.maven.cli.MavenCli.execute(MavenCli.java:555)
> at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:214)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:158)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
> at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
> at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 10 months
[JBoss JIRA] (JGRP-1797) NakackTest testReceptionOfAllMessages fails to receive all messages
by Richard Achmatowicz (JIRA)
[ https://issues.jboss.org/browse/JGRP-1797?page=com.atlassian.jira.plugin.... ]
Richard Achmatowicz commented on JGRP-1797:
-------------------------------------------
The PR makes the receiver thread synchronized. This should have no impact on the test because we are simply testing that all messages are received and in the correct order (i.e.not allowing concurrent processing of message receipt is not relevant).
Also added a little more debugging info on the assertion.
> NakackTest testReceptionOfAllMessages fails to receive all messages
> -------------------------------------------------------------------
>
> Key: JGRP-1797
> URL: https://issues.jboss.org/browse/JGRP-1797
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.2.13
> Environment: RHEL (5/24), Solaris (6/24), HPUX (1/2) where x/y means x failures over y test executions.
> Reporter: Richard Achmatowicz
> Assignee: Bela Ban
> Fix For: 3.2.13
>
> Attachments: stdout.txt
>
>
> This test does the following:
> - involves channels A, B, and C where only B and C are senders and all are receivers
> - B and C send 1000 multicast messages
> - checks that all messages are received and in the correct order
> This test is failing intermittently but quite often.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 10 months
[JBoss JIRA] (DROOLS-451) Timed rules, different name, same timer, same LHS, different RHS, one mask the other
by Matteo Mortari (JIRA)
[ https://issues.jboss.org/browse/DROOLS-451?page=com.atlassian.jira.plugin... ]
Matteo Mortari updated DROOLS-451:
----------------------------------
Attachment: 2014-03-11_18-52-25.png
20140311.drools6test.timerrulessamelhs.zip
Screenshot of rete/phreak looking promising but apparently not working, but also Java code to reproduce the failure.
> Timed rules, different name, same timer, same LHS, different RHS, one mask the other
> ------------------------------------------------------------------------------------
>
> Key: DROOLS-451
> URL: https://issues.jboss.org/browse/DROOLS-451
> Project: Drools
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 6.0.1.Final
> Reporter: Matteo Mortari
> Assignee: Mark Proctor
> Attachments: 2014-03-11_18-52-25.png, 20140311.drools6test.timerrulessamelhs.zip
>
>
> Consider the following KB:
> {code}
> rule "Dummy timer rule 1"
> timer (cron: 0 0 0 * * ?)
> when
> Integer()
> then
> insert("Dummy timer rule 1");
> System.out.println("Dummy timer rule 1");
> end
> rule "Dummy timer rule 2"
> timer (cron: 0 0 0 * * ?)
> when
> Integer()
> then
> insert("Dummy timer rule 2");
> System.out.println("Dummy timer rule 2");
> end
> {code}
> Then consider the following steps:
> # insert new Integer
> # advance clock by +1 day
> *Expected result:* 3 facts in the working memory, the original Integer, and two String.
> *Actual results:* 2 facts in the working memory, the original Integer, and only 1 String, from the former of the two rules.
> I hope this is not another duplicate report, I've done search on Jira before submitting, but kindly excuse me if I didn't found an already open bug which is a greater case of this one =)
> I will attach relevant source code to replicate the issue, and related material
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 10 months
[JBoss JIRA] (DROOLS-451) Timed rules, different name, same timer, same LHS, different RHS, one mask the other
by Matteo Mortari (JIRA)
Matteo Mortari created DROOLS-451:
-------------------------------------
Summary: Timed rules, different name, same timer, same LHS, different RHS, one mask the other
Key: DROOLS-451
URL: https://issues.jboss.org/browse/DROOLS-451
Project: Drools
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: 6.0.1.Final
Reporter: Matteo Mortari
Assignee: Mark Proctor
Attachments: 2014-03-11_18-52-25.png, 20140311.drools6test.timerrulessamelhs.zip
Consider the following KB:
{code}
rule "Dummy timer rule 1"
timer (cron: 0 0 0 * * ?)
when
Integer()
then
insert("Dummy timer rule 1");
System.out.println("Dummy timer rule 1");
end
rule "Dummy timer rule 2"
timer (cron: 0 0 0 * * ?)
when
Integer()
then
insert("Dummy timer rule 2");
System.out.println("Dummy timer rule 2");
end
{code}
Then consider the following steps:
# insert new Integer
# advance clock by +1 day
*Expected result:* 3 facts in the working memory, the original Integer, and two String.
*Actual results:* 2 facts in the working memory, the original Integer, and only 1 String, from the former of the two rules.
I hope this is not another duplicate report, I've done search on Jira before submitting, but kindly excuse me if I didn't found an already open bug which is a greater case of this one =)
I will attach relevant source code to replicate the issue, and related material
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 10 months