April 2015 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-4564) Switch to version 4 of the management schema

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFLY-4564?page=com.atlassian.jira.plugin.... ] Darran Lofthouse updated WFLY-4564: ----------------------------------- Fix Version/s: 10.0.0.Alpha1 (was: No Release) > Switch to version 4 of the management schema > -------------------------------------------- > > Key: WFLY-4564 > URL: https://issues.jboss.org/browse/WFLY-4564 > Project: WildFly > Issue Type: Task > Components: Domain Management > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 10.0.0.Alpha1 > > -- This message was sent by Atlassian JIRA (v6.3.15#6346)

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-581) CLI accepts operation requests with addresses ending on resource types

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFCORE-581?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on WFCORE-581: ------------------------------------------------ baranowb <bbaranow(a)redhat.com> changed the Status of [bug 1169342|https://bugzilla.redhat.com/show_bug.cgi?id=1169342] from POST to MODIFIED > CLI accepts operation requests with addresses ending on resource types > ---------------------------------------------------------------------- > > Key: WFCORE-581 > URL: https://issues.jboss.org/browse/WFCORE-581 > Project: WildFly Core > Issue Type: Bug > Components: CLI > Affects Versions: 1.0.0.Alpha19 > Reporter: Alexey Loubyansky > Assignee: Alexey Loubyansky > Fix For: 1.0.0.Beta1 > > > It doesn't concern the tab-completion. But if the address is entered manually and ends on a resource type, the generated operation request will target the parent resource. > [standalone@localhost:9999 /] echo-dmr /subsystem=logging/file-handler=:remove > { > "address" => [("subsystem" => "logging")], > "operation" => "remove" > } -- This message was sent by Atlassian JIRA (v6.3.15#6346)

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3930) Upgrade to PicketLink 2.7.0.Beta2

by James Bromberger (JIRA)

[ https://issues.jboss.org/browse/WFLY-3930?page=com.atlassian.jira.plugin.... ] James Bromberger commented on WFLY-3930: ---------------------------------------- Importing metadata documents from ADFS on Win2012R2 fails; these documents have an XML tag of "RoleDescriptor" in them, and Picketlink <=2.7.0 does not parse this tag - logged as bug 679: https://issues.jboss.org/browse/PLINK-679 Fixed in PicketLink 2.7.0 FINAL Current workaround: for all ADFS generated IDP metadata XML documents, edit out the RoleDescriptor from the XML document. Hence, please "Upgrade to PicketLink 2.7.0 FINAL", not 2.7.0 Beta2. Thanks. > Upgrade to PicketLink 2.7.0.Beta2 > --------------------------------- > > Key: WFLY-3930 > URL: https://issues.jboss.org/browse/WFLY-3930 > Project: WildFly > Issue Type: Component Upgrade > Components: Build System > Affects Versions: 9.0.0.Alpha1 > Reporter: Peter Skopek > Assignee: Peter Skopek > > Upgrade to PicketLink 2.7.0.Beta2 to get more users involved in. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-29) An ear file with modules in subfolders can not deploy under AS 7.0

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-29?page=com.atlassian.jira.plugin.sy... ] RH Bugzilla Integration commented on WFLY-29: --------------------------------------------- baranowb <bbaranow(a)redhat.com> changed the Status of [bug 1206635|https://bugzilla.redhat.com/show_bug.cgi?id=1206635] from POST to MODIFIED > An ear file with modules in subfolders can not deploy under AS 7.0 > ------------------------------------------------------------------ > > Key: WFLY-29 > URL: https://issues.jboss.org/browse/WFLY-29 > Project: WildFly > Issue Type: Bug > Components: EE > Reporter: Adrian Zuo > Assignee: Stuart Douglas > Fix For: 8.1.0.CR2, 8.1.0.Final > > Attachments: migrate.ear, migrate.ear > > > I have an ear file names migrate.ear which contains one ejb jar (ejb.jar) and one war file (war.war), if I put the ejb jar to a ejb folder and war file to war folder, the ear can not be depoyed. > If I move the ejb jar and war file out, it can be deployed. > Below structuer can be deployed: > ejb.jar > lib/ > lib/util-1.0-SNAPSHOT.jar > lib/version.jar > META-INF/ > META-INF/application.xml > META-INF/MANIFEST.MF > war.war > > Below structure can not be deployed: > ejb/ > ejb/ejb.jar > lib/ > lib/util-1.0-SNAPSHOT.jar > lib/version.jar > META-INF/ > META-INF/application.xml > META-INF/MANIFEST.MF > war/ > war/war.war > Below is the error: > http://community.jboss.org/message/630869#630869 -- This message was sent by Atlassian JIRA (v6.3.15#6346)

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3947) Incorrect EJB Calendar Based Timeouts

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-3947?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-3947: ----------------------------------------------- baranowb <bbaranow(a)redhat.com> changed the Status of [bug 1213875|https://bugzilla.redhat.com/show_bug.cgi?id=1213875] from POST to MODIFIED > Incorrect EJB Calendar Based Timeouts > -------------------------------------- > > Key: WFLY-3947 > URL: https://issues.jboss.org/browse/WFLY-3947 > Project: WildFly > Issue Type: Bug > Components: EJB > Reporter: Eduardo Martins > Assignee: Eduardo Martins > Fix For: 9.0.0.Beta1 > > > EJB3 CalendarBasedTimeout computes incorrects timeouts due to bad Calendar time fields manipulation, specially on DST. > A couple of examples: > 1) Timezone: "Europe/Lisbon" > Schedule Expression: any day at 1h30m > Start: 2013/03/31 03h30m > First timeout currently is 2h30m > 2) Timezone: "Australia/Lord_Howe" > Schedule Expression: any day at 2h20m, 2h40m, 3h20m, 3h40m > Start: 2013/10/06 02h41m > First timeout currently is 3h50m -- This message was sent by Atlassian JIRA (v6.3.15#6346)

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4565) FlowScoped bean not activated when packaged in WAR

by Arun Gupta (JIRA)

Arun Gupta created WFLY-4565: -------------------------------- Summary: FlowScoped bean not activated when packaged in WAR Key: WFLY-4565 URL: https://issues.jboss.org/browse/WFLY-4565 Project: WildFly Issue Type: Feature Request Components: CDI / Weld, JSF Affects Versions: 9.0.0.Beta2 Reporter: Arun Gupta Assignee: Farah Juma FlowScoped bean is activated correctly when packaged in a WAR file, but not when packaged in an EAR file. It instead throws the error as: WELD-001303: No active contexts for scope type javax.faces.flow.FlowScoped This is also explained at: http://stackoverflow.com/questions/29784654/weld-001303-with-jsf-flows-pa... -- This message was sent by Atlassian JIRA (v6.3.15#6346)

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4561) Servlet Nonblocking I/O Suppressed InputStream Closed Error

by Stuart Douglas (JIRA)

[ https://issues.jboss.org/browse/WFLY-4561?page=com.atlassian.jira.plugin.... ] Stuart Douglas commented on WFLY-4561: -------------------------------------- I don't really think that this is an error. You called close(), and the stream has closed. In general it is only an error condition if the container has closed the stream, not the user. > Servlet Nonblocking I/O Suppressed InputStream Closed Error > ----------------------------------------------------------- > > Key: WFLY-4561 > URL: https://issues.jboss.org/browse/WFLY-4561 > Project: WildFly > Issue Type: Feature Request > Components: Web (Undertow) > Affects Versions: 8.2.0.Final > Reporter: Mark S > Assignee: Stuart Douglas > Attachments: AsyncIOServletTest.java > > > Created a Nonblocking I/O Servlet by following JEE Tutorial example here: > https://docs.oracle.com/javaee/7/tutorial/servlets013.htm > Due to my Eclipse Development Environment giving me the warning "Potential resource leak: 'input' may not be closed", I made a mistake by wrapping the following line with a try-with-resources statement. > {code} > final ServletInputStream input = request.getInputStream(); > {code} > Unfortunately, no exception was thrown to indicate that the connection was already closed before processing was attempted, where I believe there should have been. > -- > I have added the relevant source code to reproduce my situation. Please see attached code. > In the attached source, I added an AsyncListener to monitor the life cycle. > h4. Case 1 > Client Request: > {code} > curl -X POST -H "Content-Type: application/x-www-form-urlencoded" --data '{"records":[{"key":"key1","value":"SGVsbG8gV29ybGQ="}]}' "http://localhost:8080/webapp/test/test"; echo > {code} > The handleRequestAsPerJeeTutorialWithInputStreamIssue method will give the following output: > {code} > 2015-04-27 10:57:20,337 (INFO ) [] AsyncIOServletTest(37): doPost(..) > 2015-04-27 10:57:50,345 (INFO ) [] AsyncIOServletTest$1(55): onTimeout called: javax.servlet.AsyncEvent@24865a17 > 2015-04-27 10:57:50,359 (INFO ) [] AsyncIOServletTest$1(48): onComplete called: javax.servlet.AsyncEvent@54ff11f3 > {code} > Client Response: > {code} > <html><head><title>Error</title></head><body>Internal Server Error</body></html> > {code} > h4. Case 2 > Client Request: > {code} > curl -X POST -H "Content-Type: application/x-www-form-urlencoded" --data '{"records":[{"key":"key1","value":"SGVsbG8gV29ybGQ="}]}' "http://localhost:8080/webapp/test/test"; echo > {code} > The handleRequestAsPerJeeTutorial method will give the following output: > {code} > 2015-04-27 10:56:32,111 (INFO ) [] AsyncIOServletTest(37): doPost(..) > 2015-04-27 10:56:32,114 (INFO ) [] AsyncIOServletTest(84): handleRequestAsPerJeeTutorial(..) > 2015-04-27 10:56:32,121 (INFO ) [] AsyncIOServletTest$2(97): onDataAvailable() > 2015-04-27 10:56:32,121 (INFO ) [] AsyncIOServletTest$2(115): onAllDataRead() > 2015-04-27 10:56:32,125 (INFO ) [] AsyncIOServletTest$1(48): onComplete called: javax.servlet.AsyncEvent@3746c9ed > {code} > Client Response: > {code} > ...the response... > {code} > ---- > It is my opinion that a closed InputStream should cause an exception of some sort. And in this case at minimum, I think that the AsyncListener's onError should be called. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4561) Servlet Nonblocking I/O Suppressed InputStream Closed Error

by Stuart Douglas (JIRA)

[ https://issues.jboss.org/browse/WFLY-4561?page=com.atlassian.jira.plugin.... ] Stuart Douglas resolved WFLY-4561. ---------------------------------- Resolution: Rejected > Servlet Nonblocking I/O Suppressed InputStream Closed Error > ----------------------------------------------------------- > > Key: WFLY-4561 > URL: https://issues.jboss.org/browse/WFLY-4561 > Project: WildFly > Issue Type: Feature Request > Components: Web (Undertow) > Affects Versions: 8.2.0.Final > Reporter: Mark S > Assignee: Stuart Douglas > Attachments: AsyncIOServletTest.java > > > Created a Nonblocking I/O Servlet by following JEE Tutorial example here: > https://docs.oracle.com/javaee/7/tutorial/servlets013.htm > Due to my Eclipse Development Environment giving me the warning "Potential resource leak: 'input' may not be closed", I made a mistake by wrapping the following line with a try-with-resources statement. > {code} > final ServletInputStream input = request.getInputStream(); > {code} > Unfortunately, no exception was thrown to indicate that the connection was already closed before processing was attempted, where I believe there should have been. > -- > I have added the relevant source code to reproduce my situation. Please see attached code. > In the attached source, I added an AsyncListener to monitor the life cycle. > h4. Case 1 > Client Request: > {code} > curl -X POST -H "Content-Type: application/x-www-form-urlencoded" --data '{"records":[{"key":"key1","value":"SGVsbG8gV29ybGQ="}]}' "http://localhost:8080/webapp/test/test"; echo > {code} > The handleRequestAsPerJeeTutorialWithInputStreamIssue method will give the following output: > {code} > 2015-04-27 10:57:20,337 (INFO ) [] AsyncIOServletTest(37): doPost(..) > 2015-04-27 10:57:50,345 (INFO ) [] AsyncIOServletTest$1(55): onTimeout called: javax.servlet.AsyncEvent@24865a17 > 2015-04-27 10:57:50,359 (INFO ) [] AsyncIOServletTest$1(48): onComplete called: javax.servlet.AsyncEvent@54ff11f3 > {code} > Client Response: > {code} > <html><head><title>Error</title></head><body>Internal Server Error</body></html> > {code} > h4. Case 2 > Client Request: > {code} > curl -X POST -H "Content-Type: application/x-www-form-urlencoded" --data '{"records":[{"key":"key1","value":"SGVsbG8gV29ybGQ="}]}' "http://localhost:8080/webapp/test/test"; echo > {code} > The handleRequestAsPerJeeTutorial method will give the following output: > {code} > 2015-04-27 10:56:32,111 (INFO ) [] AsyncIOServletTest(37): doPost(..) > 2015-04-27 10:56:32,114 (INFO ) [] AsyncIOServletTest(84): handleRequestAsPerJeeTutorial(..) > 2015-04-27 10:56:32,121 (INFO ) [] AsyncIOServletTest$2(97): onDataAvailable() > 2015-04-27 10:56:32,121 (INFO ) [] AsyncIOServletTest$2(115): onAllDataRead() > 2015-04-27 10:56:32,125 (INFO ) [] AsyncIOServletTest$1(48): onComplete called: javax.servlet.AsyncEvent@3746c9ed > {code} > Client Response: > {code} > ...the response... > {code} > ---- > It is my opinion that a closed InputStream should cause an exception of some sort. And in this case at minimum, I think that the AsyncListener's onError should be called. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1752) Concurrent message headers modification causes that message is never sent

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/JGRP-1752?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on JGRP-1752: ----------------------------------------------- dereed(a)redhat.com changed the Status of [bug 1215786|https://bugzilla.redhat.com/show_bug.cgi?id=1215786] from NEW to MODIFIED > Concurrent message headers modification causes that message is never sent > ------------------------------------------------------------------------- > > Key: JGRP-1752 > URL: https://issues.jboss.org/browse/JGRP-1752 > Project: JGroups > Issue Type: Bug > Affects Versions: 3.4.1 > Reporter: Radim Vansa > Assignee: Bela Ban > Labels: 621 > Fix For: 3.2.14, 3.4.2, 3.5 > > > Under some circumstances the TP protocol may try to add the TP header to message twice concurrently. > This happens for example when the stable message triggers retransmission while the message has been sent right now. > This may result in ArrayOutOfBoundException in Headers._putHeader and/or subsequent NullPointerException in Headers.size(). The retransmission attempt always fails, the message is never delivered. Moreover, keeping this (and possibly following) messages in the transmission table can lead to OOME. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1752) Concurrent message headers modification causes that message is never sent

by Dennis Reed (JIRA)

[ https://issues.jboss.org/browse/JGRP-1752?page=com.atlassian.jira.plugin.... ] Dennis Reed updated JGRP-1752: ------------------------------ Fix Version/s: 3.2.14 > Concurrent message headers modification causes that message is never sent > ------------------------------------------------------------------------- > > Key: JGRP-1752 > URL: https://issues.jboss.org/browse/JGRP-1752 > Project: JGroups > Issue Type: Bug > Affects Versions: 3.4.1 > Reporter: Radim Vansa > Assignee: Bela Ban > Labels: 621 > Fix For: 3.2.14, 3.4.2, 3.5 > > > Under some circumstances the TP protocol may try to add the TP header to message twice concurrently. > This happens for example when the stable message triggers retransmission while the message has been sent right now. > This may result in ArrayOutOfBoundException in Headers._putHeader and/or subsequent NullPointerException in Headers.size(). The retransmission attempt always fails, the message is never delivered. Moreover, keeping this (and possibly following) messages in the transmission table can lead to OOME. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

11 years, 2 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 April 2015