[JBoss JIRA] (WFLY-2697) Domain Mode does not start with the IBM JDK
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-2697?page=com.atlassian.jira.plugin.... ]
Brian Stansberry commented on WFLY-2697:
----------------------------------------
Reproducible with XP and the latest 32 bit JDK7 from ibm site as well.
> Domain Mode does not start with the IBM JDK
> -------------------------------------------
>
> Key: WFLY-2697
> URL: https://issues.jboss.org/browse/WFLY-2697
> Project: WildFly
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Domain Management
> Affects Versions: 8.0.0.CR1
> Environment: Windows (OS), IBM JDK 7
> Reporter: Eric Rich
> Assignee: Brian Stansberry
> Fix For: 8.0.0.Final
>
>
> When starting domain mode with the IBM JDK the following is produced 3 out of 4 times.
> [Host Controller] 16:44:06,419 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 1) JBAS014612: Operation ("start") failed - address: ([
> [Host Controller] ("host" => "master"),
> [Host Controller] ("server-config" => "server-one")
> [Host Controller] ]): java.lang.IllegalStateException: JBAS010986: Host-Controller is already shutdown.
> [Host Controller] at org.jboss.as.host.controller.ServerInventoryImpl.startServer(ServerInventoryImpl.java:175)
> [Host Controller] at org.jboss.as.host.controller.DomainModelControllerService$DelegatingServerInventory.startServer(DomainModelControllerService.java:781)
> [Host Controller] at org.jboss.as.host.controller.operations.ServerStartHandler$1.execute(ServerStartHandler.java:107)
> [Host Controller] at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:607) [jboss-as-controller-7.3.0.Final-redhat-14.jar:7.3.0.Final-redhat-14]
> [Host Controller] at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:485) [jboss-as-controller-7.3.0.Final-redhat-14.jar:7.3.0.Final-redhat-14]
> [Host Controller] at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:282)
> [jboss-as-controller-7.3.0.Final-redhat-14.jar:7.3.0.Final-redhat-14]
> [Host Controller] at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:277) [jbo
> ss-as-controller-7.3.0.Final-redhat-14.jar:7.3.0.Final-redhat-14]
> [Host Controller] at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:231) [jboss-as-contr
> oller-7.3.0.Final-redhat-14.jar:7.3.0.Final-redhat-14]
> [Host Controller] at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:137) [jboss-as-controller-7.
> 3.0.Final-redhat-14.jar:7.3.0.Final-redhat-14]
> [Host Controller] at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(Mode
> lControllerClientOperationHandler.java:173) [jboss-as-controller-7.3.0.Final-redhat-14.jar:7.3.0.Final-redhat-14]
> [Host Controller] at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$300(Mod
> elControllerClientOperationHandler.java:105) [jboss-as-controller-7.3.0.Final-redhat-14.jar:7.3.0.Final-redhat-14]
> [Host Controller] at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelC
> ontrollerClientOperationHandler.java:125) [jboss-as-controller-7.3.0.Final-redhat-14.jar:7.3.0.Final-redhat-14]
> [Host Controller] at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelC
> ontrollerClientOperationHandler.java:121) [jboss-as-controller-7.3.0.Final-redhat-14.jar:7.3.0.Final-redhat-14]
> [Host Controller] at java.security.AccessController.doPrivileged(AccessController.java:366) [vm.jar:1.7.0]
> [Host Controller] at javax.security.auth.Subject.doAs(Subject.java:572) [rt.jar:1.7.0]
> [Host Controller] at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:94) [jboss-as-controller-7.3.0.Fi
> nal-redhat-14.jar:7.3.0.Final-redhat-14]
> [Host Controller] at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(Mode
> lControllerClientOperationHandler.java:121) [jboss-as-controller-7.3.0.Final-redhat-14.jar:7.3.0.Final-redhat-14]
> [Host Controller] at org.jboss.as.protocol.mgmt.AbstractMessageHandler$2$1.doExecute(AbstractMessageHandler.java:283) [jboss-a
> s-protocol-7.3.0.Final-redhat-14.jar:7.3.0.Final-redhat-14]
> [Host Controller] at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:504) [j
> boss-as-protocol-7.3.0.Final-redhat-14.jar:7.3.0.Final-redhat-14]
> [Host Controller] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1156) [rt.jar:1.7.0]
> [Host Controller] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:626) [rt.jar:1.7.0]
> [Host Controller] at java.lang.Thread.run(Thread.java:804) [vm.jar:1.7.0]
> [Host Controller] at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.1.Final-redhat-1.jar:2.1.1.Fin
> al-redhat-1]
> [Host Controller]
--
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
12 years, 4 months
[JBoss JIRA] (WFLY-2637) Don't allow audit logs to be viewed with list-log-files and read-log-file operations
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/WFLY-2637?page=com.atlassian.jira.plugin.... ]
James Perkins commented on WFLY-2637:
-------------------------------------
Just a general comment so I don't forget, this whole thing should be looked at again. Ideally we don't want to turn {{jboss.server.log.dir}} into a generic file server directory for these commands. One option is to only allow defined file handlers files to be listed/read, but this posses security concerns.
> Don't allow audit logs to be viewed with list-log-files and read-log-file operations
> ------------------------------------------------------------------------------------
>
> Key: WFLY-2637
> URL: https://issues.jboss.org/browse/WFLY-2637
> Project: WildFly
> Issue Type: Enhancement
> Security Level: Public(Everyone can see)
> Components: Logging
> Reporter: James Perkins
> Assignee: James Perkins
>
> Currently the {{list-log-files}} and {{read-log-file}} operations will allow any file {{jboss.server.log.dir}} to be listed/viewed. Ideally only log files will be accessible, but ultimately audit logs need to definitely not be accessible.
--
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
12 years, 4 months
[JBoss JIRA] (WFLY-2641) ARQ upgrade likely to cause test failures
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFLY-2641?page=com.atlassian.jira.plugin.... ]
Tomaz Cerar commented on WFLY-2641:
-----------------------------------
Updated PR https://github.com/arquillian/arquillian-core/pull/59
> ARQ upgrade likely to cause test failures
> ------------------------------------------
>
> Key: WFLY-2641
> URL: https://issues.jboss.org/browse/WFLY-2641
> Project: WildFly
> Issue Type: Task
> Security Level: Public(Everyone can see)
> Reporter: Thomas Diesler
> Assignee: Aslak Knutsen
> Priority: Critical
> Fix For: 8.0.0.Final
>
>
> {code}
> testSimpleBundleWithWabExtension(org.jboss.test.osgi.example.webapp.WebAppTestCase) Time elapsed: 0.028 sec <<< ERROR!
> java.lang.NullPointerException: null
> at org.jboss.arquillian.junit.Arquillian$6.evaluate(Arquillian.java:290)
> at org.jboss.arquillian.junit.Arquillian$4.evaluate(Arquillian.java:226)
> at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:314)
> at org.jboss.arquillian.junit.Arquillian.access$100(Arquillian.java:46)
> at org.jboss.arquillian.junit.Arquillian$5.evaluate(Arquillian.java:240)
> {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
12 years, 4 months
[JBoss JIRA] (DROOLS-353) Evaluation of the RHS in a rule with multiple matches using noloop and update gets cut short
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/DROOLS-353?page=com.atlassian.jira.plugin... ]
RH Bugzilla Integration commented on DROOLS-353:
------------------------------------------------
Radovan Synek <rsynek(a)redhat.com> changed the Status of [bug 1034094|https://bugzilla.redhat.com/show_bug.cgi?id=1034094] from ON_QA to VERIFIED
> Evaluation of the RHS in a rule with multiple matches using noloop and update gets cut short
> --------------------------------------------------------------------------------------------
>
> Key: DROOLS-353
> URL: https://issues.jboss.org/browse/DROOLS-353
> Project: Drools
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Reporter: Mario Fusco
> Assignee: Mario Fusco
> Fix For: 6.0.1.Final
>
>
> If you have a rule with both noloop and update where there are multiple matches on the LHS, the RHS only runs for first match instead of running for all matches. The following example shows the problem:
> {code}
> @Test
> public void testMultipleNoLoop1() {
> String str =
> "import org.drools.compiler.Person\n" +
> "rule R no-loop\n" +
> "when\n" +
> " String()\n" +
> " $p : Person( $age : age )\n" +
> "then\n" +
> " modify($p) { setAge( $age + 1 ) }\n" +
> "end\n";
>
> KnowledgeBase kbase = loadKnowledgeBaseFromString(str);
> StatefulKnowledgeSession ksession = kbase.newStatefulKnowledgeSession();
>
> Person mario = new Person("Mario", 38);
>
> ksession.insert("a");
> ksession.insert("b");
> ksession.insert(mario);
> ksession.fireAllRules();
>
> assertEquals(40, mario.getAge());
> }
> {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
12 years, 4 months
[JBoss JIRA] (WFLY-2641) ARQ upgrade likely to cause test failures
by SBS JIRA Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-2641?page=com.atlassian.jira.plugin.... ]
SBS JIRA Integration updated WFLY-2641:
---------------------------------------
Forum Reference: https://community.jboss.org/message/851346#851346
> ARQ upgrade likely to cause test failures
> ------------------------------------------
>
> Key: WFLY-2641
> URL: https://issues.jboss.org/browse/WFLY-2641
> Project: WildFly
> Issue Type: Task
> Security Level: Public(Everyone can see)
> Reporter: Thomas Diesler
> Assignee: Aslak Knutsen
> Priority: Critical
> Fix For: 8.0.0.Final
>
>
> {code}
> testSimpleBundleWithWabExtension(org.jboss.test.osgi.example.webapp.WebAppTestCase) Time elapsed: 0.028 sec <<< ERROR!
> java.lang.NullPointerException: null
> at org.jboss.arquillian.junit.Arquillian$6.evaluate(Arquillian.java:290)
> at org.jboss.arquillian.junit.Arquillian$4.evaluate(Arquillian.java:226)
> at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:314)
> at org.jboss.arquillian.junit.Arquillian.access$100(Arquillian.java:46)
> at org.jboss.arquillian.junit.Arquillian$5.evaluate(Arquillian.java:240)
> {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
12 years, 4 months
[JBoss JIRA] (WFLY-2703) Undertow Broken pipe with JSFs f:ajax and h:inputText
by Andre Pankraz (JIRA)
[ https://issues.jboss.org/browse/WFLY-2703?page=com.atlassian.jira.plugin.... ]
Andre Pankraz commented on WFLY-2703:
-------------------------------------
OK, happens only with
web.xml:
<context-param>
<param-name>javax.faces.PROJECT_STAGE</param-name>
<param-value>Development</param-value>
</context-param>
not with Production, SystemTest etc.
can live with that...but should be fixed ;)
> Undertow Broken pipe with JSFs f:ajax and h:inputText
> -----------------------------------------------------
>
> Key: WFLY-2703
> URL: https://issues.jboss.org/browse/WFLY-2703
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Web (Undertow)
> Affects Versions: 8.0.0.CR1
> Environment: Linux, JDK 7
> Reporter: Andre Pankraz
>
> Combine input text with default ajax event (leave):
> <h:form id="inhaltSearch">
> <h:inputText id="contentname" size="30"
> value="#{contentList.content.searchTerms}">
> <f:ajax render=":inhaltSearch" />
> </h:inputText>
> </h:form>
> Enter value and press "Enter" (Tab works).
> A short Javascript alert appears and vanishes again.
> Stacktrace in Server:
> 14:57:59,441 ERROR [io.undertow.request] (default task-49) Blocking request failed HttpServerExchange{ POST /.../Suche.xhtml}: java.lang.RuntimeException: java.io.IOException: Broken pipe
> at io.undertow.servlet.spec.HttpServletResponseImpl.responseDone(HttpServletResponseImpl.java:513)
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:258)
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:205)
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:69)
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:134)
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:138)
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:622)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_45]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_45]
> at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_45]
> Caused by: java.io.IOException: Broken pipe
> at sun.nio.ch.FileDispatcherImpl.write0(Native Method) [rt.jar:1.7.0_45]
> at sun.nio.ch.SocketDispatcher.write(SocketDispatcher.java:47) [rt.jar:1.7.0_45]
> at sun.nio.ch.IOUtil.writeFromNativeBuffer(IOUtil.java:93) [rt.jar:1.7.0_45]
> at sun.nio.ch.IOUtil.write(IOUtil.java:65) [rt.jar:1.7.0_45]
> at sun.nio.ch.SocketChannelImpl.write(SocketChannelImpl.java:487) [rt.jar:1.7.0_45]
> at org.xnio.nio.NioSocketConduit.write(NioSocketConduit.java:150) [xnio-nio-3.1.0.CR7.jar:3.1.0.CR7]
> at io.undertow.server.protocol.http.HttpResponseConduit.write(HttpResponseConduit.java:484)
> at io.undertow.conduits.ChunkedStreamSinkConduit.flush(ChunkedStreamSinkConduit.java:189)
> at org.xnio.conduits.ConduitStreamSinkChannel.flush(ConduitStreamSinkChannel.java:147) [xnio-api-3.1.0.CR7.jar:3.1.0.CR7]
> at io.undertow.channels.DetachableStreamSinkChannel.flush(DetachableStreamSinkChannel.java:117)
> at org.xnio.channels.Channels.flushBlocking(Channels.java:63) [xnio-api-3.1.0.CR7.jar:3.1.0.CR7]
> at io.undertow.servlet.spec.ServletOutputStreamImpl.close(ServletOutputStreamImpl.java:600)
> at io.undertow.servlet.spec.HttpServletResponseImpl.responseDone(HttpServletResponseImpl.java:510)
> ... 9 more
--
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
12 years, 4 months
[JBoss JIRA] (WFLY-2689) @Producer method never called when producing a bean from a static module
by Jozef Hartinger (JIRA)
[ https://issues.jboss.org/browse/WFLY-2689?page=com.atlassian.jira.plugin.... ]
Jozef Hartinger commented on WFLY-2689:
---------------------------------------
Bean accessibility follows classloader isolation - a bean from a deployment is not considered accessible from a bean in a static module. We cannot change this until WELD-1536 is resolved.
> @Producer method never called when producing a bean from a static module
> ------------------------------------------------------------------------
>
> Key: WFLY-2689
> URL: https://issues.jboss.org/browse/WFLY-2689
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: CDI / Weld
> Affects Versions: 8.0.0.CR1
> Environment: WildFly 8.0.0.CR1
> Reporter: Pedro Igor
> Assignee: Stuart Douglas
>
> I've configured a static module for PicketLink CDI library. This library provides some extensions which are loaded fine, as described by WFLY-1370.
> However, I'm trying to deploy my application which the following producer method:
> {code}
> @Produces
> @PicketLink
> public PartitionManager getPartitionManager() {
> // produce an instance
> }
> {code}
> Where the @PicketLink annotation is a qualifier that allows my deployment to provide its own instance instead.
> In the PicketLink side, we have a injection point as follows:
> @Inject
> @PicketLink
> private Instance<PartitionManager> partitionManagerInstance;
> Where a call to partitionManagerInstance.isUnsatisfied() always returns true, even if my deployment provides a proper producer method.
> The issue here is that the producer method is never called, despite the use of qualifiers or not.
> FYI, I'm able to listen for events fired by PicketLink during the application startup as follows:
> public void observeIdentityConfigurationEvent(@Observes IdentityConfigurationEvent event) {
> // observer
> }
> Where IdentityConfigurationEvent is one of the lifecycle events fired by PicketLink during the startup.
--
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
12 years, 4 months
[JBoss JIRA] (JGRP-1765) TP: enable loopback by default and discard own multicasts
by Karim AMMOUS (JIRA)
[ https://issues.jboss.org/browse/JGRP-1765?page=com.atlassian.jira.plugin.... ]
Karim AMMOUS commented on JGRP-1765:
------------------------------------
- Use multicast allows all members to receive the data (command) at the same time. In our system, due to non-functional requirements, we must ensure the delay between the treatment done by the emitter and the receivers is less than few dozens of milliseconds.
- Useful to synchronize many actions.
- And if there is a multicast issue, the emitter *and* the receivers won't handle the message.
> TP: enable loopback by default and discard own multicasts
> ---------------------------------------------------------
>
> Key: JGRP-1765
> URL: https://issues.jboss.org/browse/JGRP-1765
> Project: JGroups
> Issue Type: Enhancement
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 3.5
>
>
> Enable {{TP.looback}} by default (deprecate and ignore prop): all messages sent by self are passed right to a thread pool to send them up again.
> When a multicast message sent by self is received, it is currently passed to a thread pool, de-serialized and only then discarded if loopback=true. This means that we create an unneeded buffer for de-serializationand perform de-serialization.
> SOLUTION: discard the multicast from self immediately when receiving it, in {{TP.receive()}}
--
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
12 years, 4 months