January 2015 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFCORE-112) Long server shut-dow with unresponsive client with opened JNDI Context

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFCORE-112?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on WFCORE-112: ------------------------------------------------ Vaclav Tunka <vtunka(a)redhat.com> changed the Status of [bug 1149621|https://bugzilla.redhat.com/show_bug.cgi?id=1149621] from MODIFIED to ON_QA > Long server shut-dow with unresponsive client with opened JNDI Context > ---------------------------------------------------------------------- > > Key: WFCORE-112 > URL: https://issues.jboss.org/browse/WFCORE-112 > Project: WildFly Core > Issue Type: Bug > Reporter: Miroslav Novak > Assignee: David Lloyd > Labels: remoting > Attachments: JNDIContext.java, testcase.zip > > > Description of problem: > If client with opened JNDI context is disconnected from network, then clean shutdown (ctrl-c) of server takes 15 minutes. > This scenario takes place, when network connections is lost between JMS clients with JNDI context and server. > Version-Release number of selected component (if applicable): > jboss-remoting-3.3.3.Final-redhat-1.jar > How reproducible: > always > Steps to Reproduce: > 1. Start EAP 6.3.1.CP.CR1 on first machine > 2. Start client which creates JNDI context on second machine (use attached JNDIContext.java) > 3. Disconnect network between client and server > 4. Try to cleanly shutdown EAP 6.3.1.CP.CR1 server (by ctrl-c) > Actual results: > It takes 15 minutes for server to shutdown. > Expected results: > Server should shutdown almost immediately. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (EJBTHREE-128) Session/MDB Jacc integration

by RH Bugzilla Integration (JIRA)

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (EJBTHREE-121) Support @EJB injection with no parameters

by RH Bugzilla Integration (JIRA)

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (JBWEB-305) No file name information in detail error when compiling the java file

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/JBWEB-305?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on JBWEB-305: ----------------------------------------------- Vaclav Tunka <vtunka(a)redhat.com> changed the Status of [bug 1155638|https://bugzilla.redhat.com/show_bug.cgi?id=1155638] from MODIFIED to ON_QA > No file name information in detail error when compiling the java file > ---------------------------------------------------------------------- > > Key: JBWEB-305 > URL: https://issues.jboss.org/browse/JBWEB-305 > Project: JBoss Web > Issue Type: Bug > Affects Versions: JBossWeb-7.4.0.GA, JBossWeb-7.5.0.GA > Reporter: Aaron Ogburn > Assignee: Remy Maucherat > Priority: Minor > > JBossWeb does not have a fix to https://issues.apache.org/bugzilla/show_bug.cgi?id=54466. Helpful file name information can be left off of compilation errors, for example: > {code} > ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[default-host].[/helloworld2].[jsp]] (http-/127.0.0.1:8080-1) JBWEB000236: Servlet.service() for servlet jsp threw exception: org.apache.jasper.JasperException: JBWEB004062: Unable to compile class for JSP: > JBWEB004061: An error occurred at line: 32 in the generated java file > The code of method _jspService(HttpServletRequest, HttpServletResponse) is exceeding the 65535 bytes limit > JBWEB004211: Stacktrace: > at org.apache.jasper.compiler.DefaultErrorHandler.javacError(DefaultErrorHandler.java:85) [jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redhat-4] > at org.apache.jasper.compiler.ErrorDispatcher.javacError(ErrorDispatcher.java:69) [jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redhat-4] > at org.apache.jasper.compiler.JDTCompiler.generateClass(JDTCompiler.java:451) [jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redhat-4] > {code} -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4149) NamingExceptions not properly handled in InitialContext

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-4149?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-4149: ----------------------------------------------- Vaclav Tunka <vtunka(a)redhat.com> changed the Status of [bug 1171243|https://bugzilla.redhat.com/show_bug.cgi?id=1171243] from MODIFIED to ON_QA > NamingExceptions not properly handled in InitialContext > ------------------------------------------------------- > > Key: WFLY-4149 > URL: https://issues.jboss.org/browse/WFLY-4149 > Project: WildFly > Issue Type: Bug > Components: Naming > Reporter: David Lloyd > Assignee: Eduardo Martins > Fix For: 9.0.0.Beta1 > > > The change in https://github.com/jbossas/jboss-eap/commit/db525bf1d90a40eb909c8f915fca7... catches all Exception and rewraps them with NamingException. This behavior is undesirable if the original exception was already a NamingException. Catch and re-throw that exception type as-is before wrapping other exceptions. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3900) Unable to inject EJB Context into CDI Interceptor

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-3900?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-3900: ----------------------------------------------- Vaclav Tunka <vtunka(a)redhat.com> changed the Status of [bug 1149646|https://bugzilla.redhat.com/show_bug.cgi?id=1149646] from MODIFIED to ON_QA > Unable to inject EJB Context into CDI Interceptor > ------------------------------------------------- > > Key: WFLY-3900 > URL: https://issues.jboss.org/browse/WFLY-3900 > Project: WildFly > Issue Type: Bug > Components: CDI / Weld > Affects Versions: 9.0.0.Alpha1 > Reporter: Brad Maxwell > Assignee: Stuart Douglas > Fix For: 9.0.0.Beta1 > > Attachments: inject-ejb-context-into-cdi-interceptor.jar, server.log > > > CDI Interceptor cannot inject EJB session context. > If the Interceptor is changed to EJB interceptor by removing the @Interceptor on the interceptor and removing it from the beans.xml, and adding @Interceptors(...) to the EJB, then it is able to inject. > See attached reproducer with source and log file. > private @Resource SessionContext sessionContext; > Caused by: javax.naming.NameNotFoundException: env/test.ServiceLoggedInterceptor/sessionContext -- service jboss.naming.context.java.comp.inject-ejb-context-into-cdi-interceptor.inject-ejb-context-into-cdi-interceptor.HelloEJB.env."test.ServiceLoggedInterceptor".sessionContext > at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:106) [wildfly-naming-9.0.0.Alpha1.jar:9.0.0.Alpha1] > at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:202) [wildfly-naming-9.0.0.Alpha1.jar:9.0.0.Alpha1] > at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:179) [wildfly-naming-9.0.0.Alpha1.jar:9.0.0.Alpha1] > at org.jboss.as.naming.InitialContext$DefaultInitialContext.lookup(InitialContext.java:235) [wildfly-naming-9.0.0.Alpha1.jar:9.0.0.Alpha1] > at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:188) [wildfly-naming-9.0.0.Alpha1.jar:9.0.0.Alpha1] > at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:184) [wildfly-naming-9.0.0.Alpha1.jar:9.0.0.Alpha1] > at javax.naming.InitialContext.lookup(InitialContext.java:411) [rt.jar:1.7.0_51] > at javax.naming.InitialContext.lookup(InitialContext.java:411) [rt.jar:1.7.0_51] > at org.jboss.as.weld.services.bootstrap.WeldResourceInjectionServices.resolveResource(WeldResourceInjectionServices.java:185) > ... 127 more -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-161) JMX monitoring is extremely memory inefficient

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFCORE-161?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on WFCORE-161: ------------------------------------------------ Vaclav Tunka <vtunka(a)redhat.com> changed the Status of [bug 1154868|https://bugzilla.redhat.com/show_bug.cgi?id=1154868] from MODIFIED to ON_QA > JMX monitoring is extremely memory inefficient > ---------------------------------------------- > > Key: WFCORE-161 > URL: https://issues.jboss.org/browse/WFCORE-161 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Reporter: Koen Janssens > Assignee: Brian Stansberry > Fix For: 1.0.0.Alpha11 > > > When reading any JMX attribute(s), I have noticed a noticeable impact on the performance of our system. After attaching a profiler, I see that getting a single attribute of a JMX bean (either using remoting or using jconsole) is generating thousands of objects, that have to cleaned up by the GC. For instance, 6000 instances of the ModelNode class are created. > A clone is made of the complete management model before executing any JMX operation. This happens in the OperationContextImpl.readResourceFromRoot class. > More background on associated forum thread -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2210) fix message endpoint isDeliveryTransacted

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-2210?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-2210: ----------------------------------------------- Vaclav Tunka <vtunka(a)redhat.com> changed the Status of [bug 1161078|https://bugzilla.redhat.com/show_bug.cgi?id=1161078] from MODIFIED to ON_QA > fix message endpoint isDeliveryTransacted > ----------------------------------------- > > Key: WFLY-2210 > URL: https://issues.jboss.org/browse/WFLY-2210 > Project: WildFly > Issue Type: Bug > Components: EJB > Affects Versions: 8.0.0.Alpha4 > Reporter: Jeff Mesnil > Assignee: Jeff Mesnil > Priority: Blocker > Fix For: 8.0.0.CR1 > > > The org.jboss.as.ejb3.inflow.MessageEndpointService#isDeliveryTransacted method is checking the transaction attribute of the method using the MethodIntf.BEAN while it should use the MethodIntf.MESSAGE_ENDPOINT type. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4089) ServletContainerInitializerDeploymentProcessor does not handle comments

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-4089?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-4089: ----------------------------------------------- Vaclav Tunka <vtunka(a)redhat.com> changed the Status of [bug 1165967|https://bugzilla.redhat.com/show_bug.cgi?id=1165967] from MODIFIED to ON_QA > ServletContainerInitializerDeploymentProcessor does not handle comments > ----------------------------------------------------------------------- > > Key: WFLY-4089 > URL: https://issues.jboss.org/browse/WFLY-4089 > Project: WildFly > Issue Type: Bug > Components: Web (Undertow) > Affects Versions: 9.0.0.Alpha1 > Reporter: James Livingston > Assignee: Stuart Douglas > Fix For: 9.0.0.Beta1 > > > ServletContainerInitializerDeploymentProcessor.loadSci() has code to read the service file, rather than using the JDK-provided mechanisms, and it does not handle comments. > The API documentation at https://docs.oracle.com/javase/7/docs/api/java/util/ServiceLoader.html says that the # symbols and all following characters on the line should be ignored. It also notes the file must be UTF-8 encoded, and ServletContainerInitializerDeploymentProcessor does not appear to force that either. > Log4j 2.1 triggers this bug (https://issues.apache.org/jira/browse/LOG4J2-890) -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (SECURITY-866) Add jboss module option to ServerLoginModule

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/SECURITY-866?page=com.atlassian.jira.plug... ] RH Bugzilla Integration commented on SECURITY-866: -------------------------------------------------- Vaclav Tunka <vtunka(a)redhat.com> changed the Status of [bug 1173493|https://bugzilla.redhat.com/show_bug.cgi?id=1173493] from MODIFIED to ON_QA > Add jboss module option to ServerLoginModule > -------------------------------------------- > > Key: SECURITY-866 > URL: https://issues.jboss.org/browse/SECURITY-866 > Project: PicketBox > Issue Type: Task > Components: PicketBox > Reporter: Jim Ma > Assignee: Jim Ma > > If the callback class isn't in the picketbox module or the deployment module, there is module option can be provided to define the module path for the callback class or validator class. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 3 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 January 2015