Bug 1167983 - javax.ejb.NoSuchEJBException should not print a stacktrace on the server console
Summary: javax.ejb.NoSuchEJBException should not print a stacktrace on the server console
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: JBoss Enterprise Application Platform 6
Classification: JBoss
Component: EJB
Version: 6.4.0
Hardware: Unspecified
OS: Unspecified
unspecified
high
Target Milestone: ---
: EAP 6.4.0
Assignee: David M. Lloyd
QA Contact: Jan Martiska
URL:
Whiteboard:
Depends On:
Blocks: 1167293
TreeView+ depends on / blocked
 
Reported: 2014-11-25 19:20 UTC by sgilda
Modified: 2019-03-01 12:29 UTC (History)
0 users

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2019-03-01 12:29:06 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Issue Tracker WFLY-4125 0 Major Closed javax.ejb.NoSuchEJBException should not print a stacktrace on the server console 2019-05-13 18:38:35 UTC

Description sgilda 2014-11-25 19:20:49 UTC
Description of problem:

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.

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?



Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1.
2.
3.

Actual results:


Expected results:


Additional info:

Comment 1 sgilda 2014-11-25 19:33:45 UTC
Created a JIRA for Wildfly: https://issues.jboss.org/browse/WFLY-4125

Comment 2 sgilda 2014-11-25 20:37:00 UTC
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


Note You need to log in before you can comment on or make changes to this bug.