November 2014 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-4125) javax.ejb.NoSuchEJBException should not print a stacktrace on the server console

by Stuart Douglas (JIRA)

[ https://issues.jboss.org/browse/WFLY-4125?page=com.atlassian.jira.plugin.... ] Stuart Douglas commented on WFLY-4125: -------------------------------------- We need a way to disable org.jboss.as.ejb3.component.interceptors.LoggingInterceptor. This violates best practice anyway, as the interceptor both logs and re-throwns. The only reason it was included is because there is a line in the spec somewhere that says that exceptions should be logged, however this should be configurable. > javax.ejb.NoSuchEJBException should not print a stacktrace on the server console > --------------------------------------------------------------------------------- > > Key: WFLY-4125 > URL: https://issues.jboss.org/browse/WFLY-4125 > Project: WildFly > Issue Type: Bug > Components: EJB > Reporter: Sande Gilda > Assignee: David Lloyd > > See related bug: https://bugzilla.redhat.com/show_bug.cgi?id=1167293 > The shopping-cart quickstart has a note in the README file that states: > Note: You also see the following EJB Invocation failed and NoSuchEJBException messages in the server log. This is the expected result because method is annotated with @Remove. This means the next invocation after the shopping cart checkout fails because the container has destroyed the instance and it is no longer available. > However, usually people see the stacktrace in the server and assume something is terribly wrong. (see https://bugzilla.redhat.com/show_bug.cgi?id=910868) > I spoke with Brad Maxwell and David M Lloyd to see if there is a way to suppress the stacktrace and only print the exception message, but it is not possible. The stacktrace doesn't really provide any additional information, and since it's thrown, the caller has access to it. > See related bug for JBoss EAP 6.4: https://bugzilla.redhat.com/show_bug.cgi?id=1167983 > David said: Looks like the place to make this change would be in org.jboss.as.ejb3.component.interceptors.LoggingInterceptor. Maybe a specific catch clause for exception types to not log? -- This message was sent by Atlassian JIRA (v6.3.8#6338)

11 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4125) javax.ejb.NoSuchEJBException should not print a stacktrace on the server console

by Sande Gilda (JIRA)

[ https://issues.jboss.org/browse/WFLY-4125?page=com.atlassian.jira.plugin.... ] Sande Gilda commented on WFLY-4125: ----------------------------------- This issue has also come up with stacktraces printed in the ejb-security-interceptors quickstart. It demonstrates how a secured EJB rejects unauthorized access. Again, it prints out something like the following, followed by a giant stacktrace. It would be nicer to just print the message. javax.ejb.EJBAccessException: JBAS014502: Invocation on method: public abstract boolean org.jboss.as.quickstarts.ejb_security_interceptors.SecuredEJBRemote.roleTwoMethod() of bean: SecuredEJB is not allowed See bug https://bugzilla.redhat.com/show_bug.cgi?id=1167640 > javax.ejb.NoSuchEJBException should not print a stacktrace on the server console > --------------------------------------------------------------------------------- > > Key: WFLY-4125 > URL: https://issues.jboss.org/browse/WFLY-4125 > Project: WildFly > Issue Type: Bug > Components: EJB > Reporter: Sande Gilda > Assignee: David Lloyd > > See related bug: https://bugzilla.redhat.com/show_bug.cgi?id=1167293 > The shopping-cart quickstart has a note in the README file that states: > Note: You also see the following EJB Invocation failed and NoSuchEJBException messages in the server log. This is the expected result because method is annotated with @Remove. This means the next invocation after the shopping cart checkout fails because the container has destroyed the instance and it is no longer available. > However, usually people see the stacktrace in the server and assume something is terribly wrong. (see https://bugzilla.redhat.com/show_bug.cgi?id=910868) > I spoke with Brad Maxwell and David M Lloyd to see if there is a way to suppress the stacktrace and only print the exception message, but it is not possible. The stacktrace doesn't really provide any additional information, and since it's thrown, the caller has access to it. > See related bug for JBoss EAP 6.4: https://bugzilla.redhat.com/show_bug.cgi?id=1167983 > David said: Looks like the place to make this change would be in org.jboss.as.ejb3.component.interceptors.LoggingInterceptor. Maybe a specific catch clause for exception types to not log? -- This message was sent by Atlassian JIRA (v6.3.8#6338)

11 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-254) logging-profiles doesn't work with Apache Common Logging

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFCORE-254?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on WFCORE-254: ------------------------------------------------ James Perkins <jperkins(a)redhat.com> changed the Status of [bug 1164063|https://bugzilla.redhat.com/show_bug.cgi?id=1164063] from NEW to CLOSED > logging-profiles doesn't work with Apache Common Logging > -------------------------------------------------------- > > Key: WFCORE-254 > URL: https://issues.jboss.org/browse/WFCORE-254 > Project: WildFly Core > Issue Type: Bug > Components: Logging > Reporter: Anders Welen > Assignee: James Perkins > Priority: Minor > Attachments: 87905.tar > > > The logging for one logging-profile ends up in another logging-profile from time to time. It's not sporadic as all logging will end up in the wrong place when things go wrong. -- This message was sent by Atlassian JIRA (v6.3.8#6338)

11 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4123) Provide a top-level 'map' operation to execute domain wide queries on the server side

by Heiko Braun (JIRA)

[ https://issues.jboss.org/browse/WFLY-4123?page=com.atlassian.jira.plugin.... ] Heiko Braun updated WFLY-4123: ------------------------------ Description: See https://github.com/hpehl/map-reduce {code:java} ModelNode address = new ModelNode(); address.add("profile", "*") .add("subsystem", "datasources") .add("data-source", "*"); ModelNode filter = new ModelNode(); filter.add("driver-name", "h2") .add("enabled", true); ModelNode op = new ModelNode(); op.get(OP).set(MAP_REDUCE); op.get(ADDRESS_TEMPLATE).set(address); op.get(FILTER).set(filter); // To return datasources where (driver-name == h2 || enabled == true) use // op.get(FILTER_CONJUNCT).set(false); {code} was:See https://github.com/hpehl/map-reduce > Provide a top-level 'map' operation to execute domain wide queries on the server side > ------------------------------------------------------------------------------------- > > Key: WFLY-4123 > URL: https://issues.jboss.org/browse/WFLY-4123 > Project: WildFly > Issue Type: Feature Request > Reporter: Heiko Braun > Assignee: Heiko Braun > Fix For: 9.0.0.Beta1 > > > See https://github.com/hpehl/map-reduce > {code:java} > ModelNode address = new ModelNode(); > address.add("profile", "*") > .add("subsystem", "datasources") > .add("data-source", "*"); > ModelNode filter = new ModelNode(); > filter.add("driver-name", "h2") > .add("enabled", true); > ModelNode op = new ModelNode(); > op.get(OP).set(MAP_REDUCE); > op.get(ADDRESS_TEMPLATE).set(address); > op.get(FILTER).set(filter); > // To return datasources where (driver-name == h2 || enabled == true) use > // op.get(FILTER_CONJUNCT).set(false); > {code} -- This message was sent by Atlassian JIRA (v6.3.8#6338)

11 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4125) javax.ejb.NoSuchEJBException should not print a stacktrace on the server console

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-4125?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration updated WFLY-4125: ------------------------------------------ Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1167983 > javax.ejb.NoSuchEJBException should not print a stacktrace on the server console > --------------------------------------------------------------------------------- > > Key: WFLY-4125 > URL: https://issues.jboss.org/browse/WFLY-4125 > Project: WildFly > Issue Type: Bug > Components: EJB > Reporter: Sande Gilda > Assignee: David Lloyd > > See related bug: https://bugzilla.redhat.com/show_bug.cgi?id=1167293 > The shopping-cart quickstart has a note in the README file that states: > Note: You also see the following EJB Invocation failed and NoSuchEJBException messages in the server log. This is the expected result because method is annotated with @Remove. This means the next invocation after the shopping cart checkout fails because the container has destroyed the instance and it is no longer available. > However, usually people see the stacktrace in the server and assume something is terribly wrong. (see https://bugzilla.redhat.com/show_bug.cgi?id=910868) > I spoke with Brad Maxwell and David M Lloyd to see if there is a way to suppress the stacktrace and only print the exception message, but it is not possible. The stacktrace doesn't really provide any additional information, and since it's thrown, the caller has access to it. > See related bug for JBoss EAP 6.4: https://bugzilla.redhat.com/show_bug.cgi?id=1167983 > David said: Looks like the place to make this change would be in org.jboss.as.ejb3.component.interceptors.LoggingInterceptor. Maybe a specific catch clause for exception types to not log? -- This message was sent by Atlassian JIRA (v6.3.8#6338)

11 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4125) javax.ejb.NoSuchEJBException should not print a stacktrace on the server console

by Sande Gilda (JIRA)

Sande Gilda created WFLY-4125: --------------------------------- Summary: javax.ejb.NoSuchEJBException should not print a stacktrace on the server console Key: WFLY-4125 URL: https://issues.jboss.org/browse/WFLY-4125 Project: WildFly Issue Type: Bug Components: EJB Reporter: Sande Gilda Assignee: David Lloyd See related bug: https://bugzilla.redhat.com/show_bug.cgi?id=1167293 The shopping-cart quickstart has a note in the README file that states: Note: You also see the following EJB Invocation failed and NoSuchEJBException messages in the server log. This is the expected result because method is annotated with @Remove. This means the next invocation after the shopping cart checkout fails because the container has destroyed the instance and it is no longer available. However, usually people see the stacktrace in the server and assume something is terribly wrong. (see https://bugzilla.redhat.com/show_bug.cgi?id=910868) I spoke with Brad Maxwell and David M Lloyd to see if there is a way to suppress the stacktrace and only print the exception message, but it is not possible. The stacktrace doesn't really provide any additional information, and since it's thrown, the caller has access to it. See related bug for JBoss EAP 6.4: https://bugzilla.redhat.com/show_bug.cgi?id=1167983 David said: Looks like the place to make this change would be in org.jboss.as.ejb3.component.interceptors.LoggingInterceptor. Maybe a specific catch clause for exception types to not log? -- This message was sent by Atlassian JIRA (v6.3.8#6338)

11 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-1712) Erroneous name attribute on root-logger after add-handler operation

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-1712?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-1712: ----------------------------------------------- James Perkins <jperkins(a)redhat.com> changed the Status of [bug 1017881|https://bugzilla.redhat.com/show_bug.cgi?id=1017881] from ASSIGNED to CLOSED > Erroneous name attribute on root-logger after add-handler operation > -------------------------------------------------------------------- > > Key: WFLY-1712 > URL: https://issues.jboss.org/browse/WFLY-1712 > Project: WildFly > Issue Type: Bug > Components: Logging > Reporter: James Perkins > Assignee: James Perkins > Priority: Minor > > Execution of the {{add-handler}} operation adds a name attribute with the handlers name to the root-logger model. > {code} > "root-logger" => {"ROOT" => { > "filter" => undefined, > "filter-spec" => undefined, > "handlers" => [ > "FILE", > "CONSOLE" > ], > "level" => "INFO", > "name" => "CONSOLE" > }} > {code} -- This message was sent by Atlassian JIRA (v6.3.8#6338)

11 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3529) UT000010: Session not found

by Rune Steinseth (JIRA)

[ https://issues.jboss.org/browse/WFLY-3529?page=com.atlassian.jira.plugin.... ] Rune Steinseth commented on WFLY-3529: -------------------------------------- I created a new issue for this: https://issues.jboss.org/browse/WELD-1802 > UT000010: Session not found > ---------------------------- > > Key: WFLY-3529 > URL: https://issues.jboss.org/browse/WFLY-3529 > Project: WildFly > Issue Type: Bug > Components: Web (Undertow) > Environment: Wildfly 8.1.0.Final , > Reporter: Youssef BIKHCHICHE > Assignee: Stuart Douglas > Attachments: WFLY-3529.tar.gz, WFLY-3529.war > > > After migration our AS from Woldfly 8.0.0 to 8.1.0 we get this issue that we think has been fixed in the previous release of wildfly. > ERREOR code : > 2014-06-20 12:45:21,092 ERROR [io.undertow.request] (default task-11) Blocking request failed HttpServerExchange{ GET /xenturion/faces/public/500.xhtml}: java.lang.RuntimeException: java.lang.IllegalStateException: UT000010: Session not found cX6YRwOmoXcB8FFUdNY2r7Te > at io.undertow.servlet.spec.RequestDispatcherImpl.error(RequestDispatcherImpl.java:408) > at io.undertow.servlet.spec.RequestDispatcherImpl.error(RequestDispatcherImpl.java:311) > at io.undertow.servlet.spec.HttpServletResponseImpl.sendError(HttpServletResponseImpl.java:128) > at io.undertow.servlet.spec.HttpServletResponseImpl.sendError(HttpServletResponseImpl.java:142) > at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:273) > at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:227) > at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:73) > at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:146) > at io.undertow.server.Connectors.executeRootHandler(Connectors.java:177) > at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:727) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_40] > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_40] > at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_40] > Caused by: java.lang.IllegalStateException: UT000010: Session not found cX6YRwOmoXcB8FFUdNY2r7Te > at io.undertow.server.session.InMemorySessionManager$SessionImpl.getAttribute(InMemorySessionManager.java:319) > at io.undertow.servlet.spec.HttpSessionImpl.getAttribute(HttpSessionImpl.java:121) > at org.springframework.security.web.context.HttpSessionSecurityContextRepository.readSecurityContextFromSession(HttpSessionSecurityContextRepository.java:144) > at org.springframework.security.web.context.HttpSessionSecurityContextRepository.loadContext(HttpSessionSecurityContextRepository.java:86) > at org.springframework.security.web.context.SecurityContextPersistenceFilter.doFilter(SecurityContextPersistenceFilter.java:82) > at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:342) > at org.springframework.security.web.FilterChainProxy.doFilterInternal(FilterChainProxy.java:192) > at org.springframework.security.web.FilterChainProxy.doFilter(FilterChainProxy.java:160) > at org.springframework.web.filter.DelegatingFilterProxy.invokeDelegate(DelegatingFilterProxy.java:343) > at org.springframework.web.filter.DelegatingFilterProxy.doFilter(DelegatingFilterProxy.java:260) > at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60) > at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132) > at io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:85) > at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:61) > at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) > at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:229) > at io.undertow.servlet.handlers.ServletInitialHandler.dispatchToPath(ServletInitialHandler.java:172) > at io.undertow.servlet.spec.RequestDispatcherImpl.error(RequestDispatcherImpl.java:402) > ====================================================== > this issue happens after a http session invalidate action and it' not a regular problems. > Best regards, > Youssef -- This message was sent by Atlassian JIRA (v6.3.8#6338)

11 years, 7 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: ----------------------------------------------- Kabir Khan <kkhan(a)redhat.com> changed the Status of [bug 1155635|https://bugzilla.redhat.com/show_bug.cgi?id=1155635] 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.8#6338)

11 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3690) Not possible to start XTS transaction on IPv6 with server bound to ::1

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-3690?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-3690: ----------------------------------------------- Kabir Khan <kkhan(a)redhat.com> changed the Status of [bug 1077156|https://bugzilla.redhat.com/show_bug.cgi?id=1077156] from MODIFIED to ON_QA > Not possible to start XTS transaction on IPv6 with server bound to ::1 > ---------------------------------------------------------------------- > > Key: WFLY-3690 > URL: https://issues.jboss.org/browse/WFLY-3690 > Project: WildFly > Issue Type: Bug > Components: Transactions, XTS > Reporter: Stefano Maestri > Assignee: Amos Feng > > Currently we have the following configuration element: <xts-environment url="http://${jboss.bind.address:127.0.0.1}:8080/ws-c11/ActivationService"/> > If bind address is set to ::1, then xts environment URL becomes http://::1:8080/ws-c11/ActivationService. This is incorrect, because IPv6 address with port number in it suppose to have brackets. > we could need to split url in 4 different attribute: > * protocol > * host > * port > * path > but there isn't a easy way to do the transformer by adding these new attributes. So it's just another solution to split the url and check the address if startsWith ::1, then it needs to add the brackets and join them again. -- This message was sent by Atlassian JIRA (v6.3.8#6338)

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 November 2014