December 2014 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-4193) Update spec versions on Quickstarts README.md files

by Rafael Benevides (JIRA)

[ https://issues.jboss.org/browse/WFLY-4193?page=com.atlassian.jira.plugin.... ] Rafael Benevides updated WFLY-4193: ----------------------------------- Summary: Update spec versions on Quickstarts README.md files (was: Update spec versions on Kitchensink README.md files) > Update spec versions on Quickstarts README.md files > --------------------------------------------------- > > Key: WFLY-4193 > URL: https://issues.jboss.org/browse/WFLY-4193 > Project: WildFly > Issue Type: Enhancement > Reporter: Rafael Benevides > Assignee: Rafael Benevides > Labels: quickstart, quickstarts > > On Every Kitchensink Quickstart, there's a "What is it?" section that contains JAVA EE 6 spec versions. It should be updated to JAVA EE 7. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4031) Wildfly Quickstarts using old namespaces for beans.xml, faces-config.xml and persistence.xml

by Rafael Benevides (JIRA)

[ https://issues.jboss.org/browse/WFLY-4031?page=com.atlassian.jira.plugin.... ] Rafael Benevides resolved WFLY-4031. ------------------------------------ Resolution: Done Fixed beans.xml and persistence.xml: https://github.com/wildfly/quickstart/commit/622dfb931e791f91ee7762129d86... > Wildfly Quickstarts using old namespaces for beans.xml, faces-config.xml and persistence.xml > -------------------------------------------------------------------------------------------- > > Key: WFLY-4031 > URL: https://issues.jboss.org/browse/WFLY-4031 > Project: WildFly > Issue Type: Bug > Reporter: Rafael Benevides > Assignee: Rafael Benevides > Priority: Minor > Labels: quickstarts, > > All Wildfly quickstarts have the wrong XML namespaces for the following files. > ./src/main/webapp/WEB-INF/beans.xml > ./src/main/webapp/WEB-INF/faces-config.xml > beans.xml and faces-config.xml are using java.sun.com-style namespaces instead of xmlns.jcp.org-style namespaces. > This affects the wildfly archetypes as well -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4031) Wildfly Quickstarts using old namespaces for beans.xml, faces-config.xml and persistence.xml

by Rafael Benevides (JIRA)

[ https://issues.jboss.org/browse/WFLY-4031?page=com.atlassian.jira.plugin.... ] Rafael Benevides reassigned WFLY-4031: -------------------------------------- Assignee: Rafael Benevides (was: Sebastian Łaskawiec) > Wildfly Quickstarts using old namespaces for beans.xml, faces-config.xml and persistence.xml > -------------------------------------------------------------------------------------------- > > Key: WFLY-4031 > URL: https://issues.jboss.org/browse/WFLY-4031 > Project: WildFly > Issue Type: Bug > Reporter: Rafael Benevides > Assignee: Rafael Benevides > Priority: Minor > Labels: quickstarts, > > All Wildfly quickstarts have the wrong XML namespaces for the following files. > ./src/main/webapp/WEB-INF/beans.xml > ./src/main/webapp/WEB-INF/faces-config.xml > beans.xml and faces-config.xml are using java.sun.com-style namespaces instead of xmlns.jcp.org-style namespaces. > This affects the wildfly archetypes as well -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3266) Exception are hidden by retry and end in a EJBCLIENT000032 Exception - the underlying client or server side cause is swallowed

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-3266?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-3266: ----------------------------------------------- Kabir Khan <kkhan(a)redhat.com> changed the Status of [bug 1088463|https://bugzilla.redhat.com/show_bug.cgi?id=1088463] from POST to MODIFIED > Exception are hidden by retry and end in a EJBCLIENT000032 Exception - the underlying client or server side cause is swallowed > ------------------------------------------------------------------------------------------------------------------------------ > > Key: WFLY-3266 > URL: https://issues.jboss.org/browse/WFLY-3266 > Project: WildFly > Issue Type: Bug > Components: EJB > Affects Versions: 8.0.0.Final > Reporter: Wolf-Dieter Fink > Assignee: David Lloyd > Priority: Critical > > In case of large parameter input for EJB invocations the ejb-client throw the Exception below. > The underlying OutOfMemory is complete hidden, neither in the server.log nor in the ejb-client with TRACE a hint will be found. > java.lang.IllegalStateException: EJBCLIENT000032: Cannot retry a request which hasn't previously been completed > at org.jboss.ejb.client.EJBClientInvocationContext.retryRequest(EJBClientInvocationContext.java:200) > at org.jboss.ejb.client.EJBInvocationHandler.sendRequestWithPossibleRetries(EJBInvocationHandler.java:256) > at org.jboss.ejb.client.EJBInvocationHandler.sendRequestWithPossibleRetries(EJBInvocationHandler.java:265) > at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:198) > at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:181) > at org.jboss.ejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:144) > at com.sun.proxy.$Proxy6.uploadData(Unknown Source) > at de.info.biene.konsens.TestServiceWithAPITest.testUploadData(TestServiceWithAPITest.java:81) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:606) > at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47) > at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) > at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44) > at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17) > at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271) > at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70) > at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50) > at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238) > at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63) > at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236) > at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53) > at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229) > at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26) > at org.junit.runners.ParentRunner.run(ParentRunner.java:309) > at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:252) > at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:141) > at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:112) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:606) > at org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:189) > at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:165) > at org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:85) > at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:115) > at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:75) -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-438) The CLI freezes in phase of requesting username/password

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFCORE-438?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on WFCORE-438: ------------------------------------------------ Kabir Khan <kkhan(a)redhat.com> changed the Status of [bug 1169300|https://bugzilla.redhat.com/show_bug.cgi?id=1169300] from POST to MODIFIED > The CLI freezes in phase of requesting username/password > -------------------------------------------------------- > > Key: WFCORE-438 > URL: https://issues.jboss.org/browse/WFCORE-438 > Project: WildFly Core > Issue Type: Bug > Components: CLI > Affects Versions: 1.0.0.Alpha13 > Reporter: Tomas Hofman > Assignee: Tomas Hofman > Fix For: 1.0.0.Alpha15 > > > CLI doesn't terminate -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-440) Upgrade JBoss AESH from 0.33.12.redhat-1 to 0.33.14.redhat-1

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFCORE-440?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on WFCORE-440: ------------------------------------------------ Kabir Khan <kkhan(a)redhat.com> changed the Status of [bug 1169858|https://bugzilla.redhat.com/show_bug.cgi?id=1169858] from NEW to MODIFIED > Upgrade JBoss AESH from 0.33.12.redhat-1 to 0.33.14.redhat-1 > ------------------------------------------------------------ > > Key: WFCORE-440 > URL: https://issues.jboss.org/browse/WFCORE-440 > Project: WildFly Core > Issue Type: Component Upgrade > Components: CLI > Affects Versions: 1.0.0.Alpha13 > Reporter: Tomas Hofman > Assignee: Alexey Loubyansky > > AESH needs to be upgraded due to https://issues.jboss.org/browse/WFCORE-438 -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4197) Upgrade HAL to 2.5.2.Final

by Harald Pehl (JIRA)

Harald Pehl created WFLY-4197: --------------------------------- Summary: Upgrade HAL to 2.5.2.Final Key: WFLY-4197 URL: https://issues.jboss.org/browse/WFLY-4197 Project: WildFly Issue Type: Component Upgrade Components: Web Console Reporter: Harald Pehl Assignee: Harald Pehl Fix For: 9.0.0.Beta1 -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4197) Upgrade HAL to 2.5.2.Final

by Harald Pehl (JIRA)

[ https://issues.jboss.org/browse/WFLY-4197?page=com.atlassian.jira.plugin.... ] Harald Pehl updated WFLY-4197: ------------------------------ Git Pull Request: (was: https://github.com/wildfly/wildfly/pull/7009) > Upgrade HAL to 2.5.2.Final > -------------------------- > > Key: WFLY-4197 > URL: https://issues.jboss.org/browse/WFLY-4197 > Project: WildFly > Issue Type: Component Upgrade > Components: Web Console > Reporter: Harald Pehl > Assignee: Harald Pehl > Fix For: 9.0.0.Beta1 > > -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3895) Blocking request failed HttpServerExchange{ POST /fabric/jolokia}

by Stuart Douglas (JIRA)

[ https://issues.jboss.org/browse/WFLY-3895?page=com.atlassian.jira.plugin.... ] Stuart Douglas commented on WFLY-3895: -------------------------------------- You are going to need to provide more details. Can you email undertow-dev(a)lists.jboss.org with more details about your code? By your description and looking at the stack trace it kinda looks like something is trying to write to the first request which as already ended. > Blocking request failed HttpServerExchange{ POST /fabric/jolokia} > ----------------------------------------------------------------- > > Key: WFLY-3895 > URL: https://issues.jboss.org/browse/WFLY-3895 > Project: WildFly > Issue Type: Bug > Components: Web (Undertow) > Affects Versions: 8.1.0.Final > Reporter: Thomas Diesler > Assignee: Stuart Douglas > Fix For: 9.0.0.Beta1 > > > This happens with an Http POST request for a Jolokia MBean operation. > Attribute reads seem to work. > {code} > 10:28:10,823 ERROR [io.undertow.request] (default task-3) Blocking request failed HttpServerExchange{ POST /fabric/jolokia}: java.lang.IllegalStateException: UT000004: getResponseChannel() has already been called > at io.undertow.server.protocol.http.HttpContinue.createResponseSender(HttpContinue.java:78) > at io.undertow.server.handlers.HttpContinueReadHandler$ContinueConduit.read(HttpContinueReadHandler.java:104) > at org.xnio.conduits.ConduitStreamSourceChannel.read(ConduitStreamSourceChannel.java:127) [xnio-api-3.2.2.Final.jar:3.2.2.Final] > at io.undertow.channels.DetachableStreamSourceChannel.read(DetachableStreamSourceChannel.java:181) > at io.undertow.server.HttpServerExchange$ReadDispatchChannel.read(HttpServerExchange.java:1952) > at org.xnio.channels.Channels.readBlocking(Channels.java:294) [xnio-api-3.2.2.Final.jar:3.2.2.Final] > at io.undertow.servlet.spec.ServletInputStreamImpl.readIntoBuffer(ServletInputStreamImpl.java:146) > at io.undertow.servlet.spec.ServletInputStreamImpl.close(ServletInputStreamImpl.java:218) > at io.undertow.servlet.spec.HttpServletRequestImpl.closeAndDrainRequest(HttpServletRequestImpl.java:588) > at io.undertow.servlet.core.ServletBlockingHttpExchange.close(ServletBlockingHttpExchange.java:69) > at io.undertow.server.HttpServerExchange.endExchange(HttpServerExchange.java:1404) > at io.undertow.server.Connectors.executeRootHandler(Connectors.java:193) > at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:727) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_67] > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_67] > at java.lang.Thread.run(Thread.java:745) [rt.jar:1.7.0_67] > {code} -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 7 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-672) Drools audit log view cannot be opened

by Jose Luis Melgar (JIRA)

[ https://issues.jboss.org/browse/DROOLS-672?page=com.atlassian.jira.plugin... ] Jose Luis Melgar updated DROOLS-672: ------------------------------------ Description: On behalf of Gergely Bacso: {quote} From: Mark Proctor Sent: ‎20/‎12/‎2014 21:15 To: drools-setup(a)googlegroups.com Cc: Bob Brodt Subject: Re: [drools-setup] Drools audit log view cannot be opened please open a JIRA, so we can be sure to fix this. Thanks Mark {quote} {quote} On 19 Dec 2014, at 18:19, Gergely Bacsó wrote: Hi, First of all: this problem can be reproduced with only a single audit file. I managed to get closer to the solution by spending a few hours reading Drools source code: The Eclipse plugin has a class called AuditView, this class expects RuleFlowGroupNode-s in the right sequence, or it blows up: http://grepcode.com/file/repo1.maven.org/maven2/org.drools/org.drools.ecl... (see line 515, stack.pop()) Since my audit logs for some reason contain several of AFTER_RULEFLOW_GROUP_DEACTIVATED entries without having any BEFORE_RULEFLOW_GROUP_DEACTIVATED entries preceding them, the AuditView fails to parse the log.Currently I am manually removing these non-matched entries to be able to open the file, and planning to spend some time on further analysis after the holidays. Gergely {quote} was: On behalf of Gergely Bacso: {quote} From: Mark Proctor Sent: ‎20/‎12/‎2014 21:15 To: drools-setup(a)googlegroups.com Cc: Bob Brodt Subject: Re: [drools-setup] Drools audit log view cannot be opened please open a JIRA, so we can be sure to fix this. Thanks Mark {quote} {quote} On 19 Dec 2014, at 18:19, Gergely Bacsó <gergely.bacso(a)gmail.com> wrote: Hi, First of all: this problem can be reproduced with only a single audit file. I managed to get closer to the solution by spending a few hours reading Drools source code: The Eclipse plugin has a class called AuditView, this class expects RuleFlowGroupNode-s in the right sequence, or it blows up: http://grepcode.com/file/repo1.maven.org/maven2/org.drools/org.drools.ecl... (see line 515, stack.pop()) Since my audit logs for some reason contain several of AFTER_RULEFLOW_GROUP_DEACTIVATED entries without having any BEFORE_RULEFLOW_GROUP_DEACTIVATED entries preceding them, the AuditView fails to parse the log.Currently I am manually removing these non-matched entries to be able to open the file, and planning to spend some time on further analysis after the holidays. Gergely {quote} > Drools audit log view cannot be opened > -------------------------------------- > > Key: DROOLS-672 > URL: https://issues.jboss.org/browse/DROOLS-672 > Project: Drools > Issue Type: Bug > Affects Versions: 6.0.1.Final > Reporter: Jose Luis Melgar > Assignee: Mark Proctor > Labels: Drools > > On behalf of Gergely Bacso: > {quote} > From: Mark Proctor > Sent: ‎20/‎12/‎2014 21:15 > To: drools-setup(a)googlegroups.com > Cc: Bob Brodt > Subject: Re: [drools-setup] Drools audit log view cannot be opened > please open a JIRA, so we can be sure to fix this. > Thanks > Mark > {quote} > {quote} > On 19 Dec 2014, at 18:19, Gergely Bacsó wrote: > Hi, > First of all: this problem can be reproduced with only a single audit file. > I managed to get closer to the solution by spending a few hours reading Drools source code: > The Eclipse plugin has a class called AuditView, this class expects RuleFlowGroupNode-s in the right sequence, or it blows up: > http://grepcode.com/file/repo1.maven.org/maven2/org.drools/org.drools.ecl... (see line 515, stack.pop()) > Since my audit logs for some reason contain several of > AFTER_RULEFLOW_GROUP_DEACTIVATED entries without having any BEFORE_RULEFLOW_GROUP_DEACTIVATED entries preceding them, the AuditView fails to parse the log.Currently I am manually removing these non-matched entries to be able to open the file, and planning to spend some time on further analysis after the holidays. > Gergely > {quote} -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 7 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira December 2014