May 2015 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-3778) Tests in Manualmode test suite fail occasionally

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-3778?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-3778: ----------------------------------------------- baranowb <bbaranow(a)redhat.com> changed the Status of [bug 1105003|https://bugzilla.redhat.com/show_bug.cgi?id=1105003] from POST to MODIFIED > Tests in Manualmode test suite fail occasionally > ------------------------------------------------ > > Key: WFLY-3778 > URL: https://issues.jboss.org/browse/WFLY-3778 > Project: WildFly > Issue Type: Bug > Components: Remoting, Test Suite > Affects Versions: 9.0.0.Alpha1 > Environment: Oracle Solaris SPARC 10, Oracle JDK 1.7.0_67. > Reporter: Frank Langelage > Assignee: David Lloyd > Attachments: org.jboss.as.test.manualmode.management.cli.VaultPasswordsInCLITestCase-output.txt, org.jboss.as.test.manualmode.management.cli.VaultPasswordsInCLITestCase.txt, TEST-org.jboss.as.test.manualmode.management.cli.VaultPasswordsInCLITestCase.xml > > > I always see failures in one or few test of manualmode test suite on this platform. I not remember to have seen them on Windows 7. > But I saw a very similar failure today on Linux first time for PR 6638. > See https://github.com/wildfly/wildfly/pull/6638. > Last failure on my machine: > {noformat} > Running org.jboss.as.test.manualmode.management.cli.VaultPasswordsInCLITestCase > Tests run: 4, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 72.186 sec <<< FAILURE! - in org.jboss.as.test.manualmode.management.cli.VaultPasswordsInCLITestCase > testRightVaultPassword(org.jboss.as.test.manualmode.management.cli.VaultPasswordsInCLITestCase) Time elapsed: 6.23 sec <<< FAILURE! > java.lang.AssertionError: Password should be right and authentication successful > Expected: a string containing "\"outcome\" => \"success\"" > but: was "0: INFO [org.jboss.modules] JBoss Modules version 1.3.4.Final > INFO [org.jboss.security] PBOX000361: Default Security Vault Implementation Initialized and Ready > INFO [org.xnio] XNIO version 3.3.0.Beta1 > INFO [org.xnio.nio] XNIO NIO Implementation Version 3.3.0.Beta1 > INFO [org.jboss.remoting] JBoss Remoting version 4.0.3.Final > " > at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:20) > at org.junit.Assert.assertThat(Assert.java:865) > at org.jboss.as.test.manualmode.management.cli.VaultPasswordsInCLITestCase.testRightVaultPassword(VaultPasswordsInCLITestCase.java:158) > {noformat} -- This message was sent by Atlassian JIRA (v6.3.15#6346)

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-659) standalone.sh fails to start server with debug argument on solaris 10 and HP-UX hosts

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFCORE-659?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on WFCORE-659: ------------------------------------------------ baranowb <bbaranow(a)redhat.com> changed the Status of [bug 1064763|https://bugzilla.redhat.com/show_bug.cgi?id=1064763] from POST to MODIFIED > standalone.sh fails to start server with debug argument on solaris 10 and HP-UX hosts > ------------------------------------------------------------------------------------- > > Key: WFCORE-659 > URL: https://issues.jboss.org/browse/WFCORE-659 > Project: WildFly Core > Issue Type: Bug > Affects Versions: 1.0.0.Beta6 > Environment: HP-UX, Solaris > Reporter: Tomas Hofman > Assignee: Tomas Hofman > > Copy of https://bugzilla.redhat.com/show_bug.cgi?id=1064763 > Description of problem: > I am unable to start standalone server with --debug [PORT] argument on Solaris 10 hosts. > SunOS 5.10 Generic_142910-17 i86pc i386 i86pc > [user@host bin]$ ./standalone.sh --debug > ./standalone.sh: cannot shift > [user@host bin]$ ./standalone.sh --debug 8787 > ./standalone.sh: bad substitution > SunOS 5.10 Generic_118833-36 sun4v sparc SUNW,Sun-Fire-T1000 > [user@host bin]$ ./standalone.sh --debug > ./standalone.sh: cannot shift > [user@host bin]$ ./standalone.sh --debug 8787 > ./standalone.sh: bad substitution > Version-Release number of selected component (if applicable): > EAP 6.3.0.DR0 > How reproducible: > Always > Steps to Reproduce: > 1. Navigate to $JBOSS_HOME/bin and run: ./standalone.sh --debug [PORT] > Actual results: > Server fails to start > Expected results: > Server will start with debugger attached to $PORT (8787 if no $PORT) -- This message was sent by Atlassian JIRA (v6.3.15#6346)

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBMETA-385) Add overridable flag to servlet metadata

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/JBMETA-385?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on JBMETA-385: ------------------------------------------------ baranowb <bbaranow(a)redhat.com> changed the Status of [bug 1094248|https://bugzilla.redhat.com/show_bug.cgi?id=1094248] from POST to MODIFIED > Add overridable flag to servlet metadata > ---------------------------------------- > > Key: JBMETA-385 > URL: https://issues.jboss.org/browse/JBMETA-385 > Project: JBoss Metadata > Issue Type: Enhancement > Components: web > Affects Versions: 7.2.1.Final > Reporter: James Livingston > Assignee: Bartosz Baranowski > Fix For: 7.2.2.Final > > > To resolve https://bugzilla.redhat.com/show_bug.cgi?id=1094248, I believe we need an additional 'overridable' flag on the servlet metadata which indicates whether ServletContainerInitializers (and other code using servlet dynamic registration) should be allowed to override the servlet. Normally this is not allowed, however JBWeb's internal use of DefaultServlet to handle static resources should be. > This only needs to go into 7, since the Undertow subsystem in Wildfly handles this quite differently, so does not need to pass a flag between components. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBWEB-310) Allow servlets to be marked overridable via Servlet registration API

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/JBWEB-310?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on JBWEB-310: ----------------------------------------------- baranowb <bbaranow(a)redhat.com> changed the Status of [bug 1094248|https://bugzilla.redhat.com/show_bug.cgi?id=1094248] from POST to MODIFIED > Allow servlets to be marked overridable via Servlet registration API > -------------------------------------------------------------------- > > Key: JBWEB-310 > URL: https://issues.jboss.org/browse/JBWEB-310 > Project: JBoss Web > Issue Type: Enhancement > Affects Versions: JBossWeb-7.5.0.GA > Reporter: James Livingston > Assignee: Remy Maucherat > Attachments: JBWEB-310.patch > > > To resolve https://bugzilla.redhat.com/show_bug.cgi?id=1094248, JBossWeb needs to add an 'overridable' flag on Wrapper, and not treat new mappings as conflicting if the one previously using the mapping was marked overridable. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4580) Lifecycle interceptors do not work

by Stuart Douglas (JIRA)

[ https://issues.jboss.org/browse/WFLY-4580?page=com.atlassian.jira.plugin.... ] Stuart Douglas resolved WFLY-4580. ---------------------------------- Resolution: Done This works fine, see https://github.com/wildfly/wildfly/pull/7410 for a test case. > Lifecycle interceptors do not work > ---------------------------------- > > Key: WFLY-4580 > URL: https://issues.jboss.org/browse/WFLY-4580 > Project: WildFly > Issue Type: Bug > Components: CDI / Weld > Affects Versions: JBoss AS7 7.1.1.Final, 8.2.0.Final > Reporter: Xavier Dury > Assignee: Stuart Douglas > > I've been trying to use lifecycle interceptors (intercepting PostConstruct and PreDestroy, see https://issues.jboss.org/browse/WELD-1346 for reference) in my project and those do not seem to work at all (nor on enterprise managed beans nor on regular CDI managed beans). > I tried on both JBoss AS 7.1.1 and Wildfly 8.2.0 but lifecycle interceptors are never called while other interceptors (AroundInvoke) are. > I tested the same code on OpenEJB and it works. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBLOGGING-114) jboss-logging OSGi bundle requiring optional packages

by James Perkins (JIRA)

[ https://issues.jboss.org/browse/JBLOGGING-114?page=com.atlassian.jira.plu... ] James Perkins closed JBLOGGING-114. ----------------------------------- Resolution: Duplicate Issue > jboss-logging OSGi bundle requiring optional packages > ----------------------------------------------------- > > Key: JBLOGGING-114 > URL: https://issues.jboss.org/browse/JBLOGGING-114 > Project: JBoss Logging > Issue Type: Bug > Reporter: Steve Ebersole > Assignee: James Perkins > > Apparently jboss-logging places a non-optional dependency on log4j: > {noformat} > [22:04] <sebersole> dmlloyd: if you are around... > [22:04] <sebersole> we are having trouble with hibernate-osgi because of jboss-logging jar > [22:04] <sebersole> it essentially requires log4j > [22:05] <sebersole> [22:03] <brmeyer> their manifest has resolution:=optional for every org.apache.log4j package *except* for .message > [22:05] <sebersole> tbh, thats all just gibberish to me. he might as well be speaking chinese > [22:06] <sebersole> but when we try to deploy into karaf, we do get errors installing our features because the jboss-logging bundle fails to start because log4j isnt installed > [22:06] <sebersole> it works when we install log4j first as well > [22:06] <sebersole> even though we are not using log4j > {noformat} -- This message was sent by Atlassian JIRA (v6.3.15#6346)

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3962) onComplete for async listeners not always called

by Stuart Douglas (JIRA)

[ https://issues.jboss.org/browse/WFLY-3962?page=com.atlassian.jira.plugin.... ] Stuart Douglas commented on WFLY-3962: -------------------------------------- Thomas, can you confirm that my last changes fixed the issue? > onComplete for async listeners not always called > ------------------------------------------------ > > Key: WFLY-3962 > URL: https://issues.jboss.org/browse/WFLY-3962 > Project: WildFly > Issue Type: Bug > Components: Web (Undertow) > Affects Versions: 8.0.0.Final, 8.1.0.Final > Reporter: Heiko Rupp > Assignee: Stuart Douglas > Fix For: 8.2.0.Final, 9.0.0.CR2 > > > I have a servlet filter that does > chain.doFilter(requestWrapper, responseWrapper); > if (request.isAsyncStarted()) { > asyncListener = request.getAsyncContext().createListener(JsonPAsyncListener.class); > request.getAsyncContext().addListener(asyncListener, requestWrapper, responseWrapper); > } > And (sometimes) this works well so that the onComplete() method of the listener is called. > But this does not happen always. In some (repeatable) condition none of the callback methods in my AsyncListener are called. > I was first thinking that the servlet (resteasy) behind chain.doFilter() is so fast that it completes > before I can add the listener. > But then I tried adding a Thread.sleep() in the RE code which did not change anything. > Similar when I do a startAsync() and add the listener before calling chain.doFilter() > This happens both on Wfly 8.0 and 8.1 > Basically it boils down that if the "backend" uses Futures.immediateFuture(result) , onComplete is not called. > I have created a as small as possible war file + a read me on how to drive that via curl. > See https://github.com/pilhuhn/misc/tree/master/web-goo > I just added 2 examples to the readme file that show that if no > wrapping by the filter is requested, the resteasy code works with > both Futures.immediate... and Futures.transform(...) -- This message was sent by Atlassian JIRA (v6.3.15#6346)

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBLOGGING-114) jboss-logging OSGi bundle requiring optional packages

by Brett Meyer (JIRA)

[ https://issues.jboss.org/browse/JBLOGGING-114?page=com.atlassian.jira.plu... ] Brett Meyer commented on JBLOGGING-114: --------------------------------------- Hey James, yes, appears so. Thanks! > jboss-logging OSGi bundle requiring optional packages > ----------------------------------------------------- > > Key: JBLOGGING-114 > URL: https://issues.jboss.org/browse/JBLOGGING-114 > Project: JBoss Logging > Issue Type: Bug > Reporter: Steve Ebersole > Assignee: James Perkins > > Apparently jboss-logging places a non-optional dependency on log4j: > {noformat} > [22:04] <sebersole> dmlloyd: if you are around... > [22:04] <sebersole> we are having trouble with hibernate-osgi because of jboss-logging jar > [22:04] <sebersole> it essentially requires log4j > [22:05] <sebersole> [22:03] <brmeyer> their manifest has resolution:=optional for every org.apache.log4j package *except* for .message > [22:05] <sebersole> tbh, thats all just gibberish to me. he might as well be speaking chinese > [22:06] <sebersole> but when we try to deploy into karaf, we do get errors installing our features because the jboss-logging bundle fails to start because log4j isnt installed > [22:06] <sebersole> it works when we install log4j first as well > [22:06] <sebersole> even though we are not using log4j > {noformat} -- This message was sent by Atlassian JIRA (v6.3.15#6346)

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2900) Performance issue with Xalan transformer and very large text nodes

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFLY-2900?page=com.atlassian.jira.plugin.... ] Brian Stansberry updated WFLY-2900: ----------------------------------- Git Pull Request: https://github.com/jboss/xalan-j/pull/4 (was: https://github.com/jboss/xalan-j/pull/2) > Performance issue with Xalan transformer and very large text nodes > ------------------------------------------------------------------ > > Key: WFLY-2900 > URL: https://issues.jboss.org/browse/WFLY-2900 > Project: WildFly > Issue Type: Bug > Components: XML Frameworks > Reporter: Kyle Lape > Assignee: Jason Greene > Priority: Blocker > Fix For: 9.0.0.CR1 > > > It has been observed that when using the {{Transfomer}} to convert a {{StreamSource}} to {{DOMResult}}, the performance of Transform gets worse as the size of the > character data increases. If you have a 50MB text blob in XML, this will take a very long time to finish. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBLOGGING-114) jboss-logging OSGi bundle requiring optional packages

by James Perkins (JIRA)

[ https://issues.jboss.org/browse/JBLOGGING-114?page=com.atlassian.jira.plu... ] James Perkins commented on JBLOGGING-114: ----------------------------------------- Not being an OSGi expert, will this fix it? https://github.com/jboss-logging/jboss-logging/pull/19 > jboss-logging OSGi bundle requiring optional packages > ----------------------------------------------------- > > Key: JBLOGGING-114 > URL: https://issues.jboss.org/browse/JBLOGGING-114 > Project: JBoss Logging > Issue Type: Bug > Reporter: Steve Ebersole > Assignee: James Perkins > > Apparently jboss-logging places a non-optional dependency on log4j: > {noformat} > [22:04] <sebersole> dmlloyd: if you are around... > [22:04] <sebersole> we are having trouble with hibernate-osgi because of jboss-logging jar > [22:04] <sebersole> it essentially requires log4j > [22:05] <sebersole> [22:03] <brmeyer> their manifest has resolution:=optional for every org.apache.log4j package *except* for .message > [22:05] <sebersole> tbh, thats all just gibberish to me. he might as well be speaking chinese > [22:06] <sebersole> but when we try to deploy into karaf, we do get errors installing our features because the jboss-logging bundle fails to start because log4j isnt installed > [22:06] <sebersole> it works when we install log4j first as well > [22:06] <sebersole> even though we are not using log4j > {noformat} -- 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 May 2015