Issue Details (XML | Word | Printable)

Key: GLASSFISH-17417
Type: Bug Bug
Status: Resolved Resolved
Resolution: Fixed
Priority: Major Major
Assignee: sakshi.jain
Reporter: atomicknight
Votes: 0
Watchers: 1

If you were logged in you would be able to see more operations.

Embedded Glassfish is hard-coded to print reporting output to stdout

Created: 12/Oct/11 10:13 PM   Updated: 11/Oct/12 03:53 PM   Resolved: 22/Nov/11 09:03 AM
Component/s: embedded
Affects Version/s: 3.1.2_b01
Fix Version/s: 3.1.2, 4.0

Time Tracking:
Not Specified

File Attachments: 1. Zip Archive (3 kB) 12/Oct/11 10:13 PM - atomicknight


Java 6u27

Tags: embedded 3_1_2-review
Participants: atomicknight, Bhavanishankar, sakshi.jain, scatari and Tom Mueller

 Description  « Hide

Original forum thread:

Starting with 3.1.1-b07, the embedded container always prints reporting output to stdout, which interferes with applications that print data to stdout to be consumed by other programs (e.g. in a pipeline). This is a regression from 3.1, where no such output was emitted.

A test case is attached, with profiles for 3.1.1 (the final release), 3.1.1-b07 (the initial build exhibiting the issue), 3.1.1-b06 (the latest build not exhibiting the issue), and 3.1. Running 'mvn package' with the appropriate profile executes the test case. The expected output is a single line with "Hello!" during the execution of the exec:exec goal.

Tom Mueller added a comment - 13/Oct/11 01:48 PM

The output is coming from the following line in (line


The reason that this started showing up in 3.1.1-b07 is probably due to revision 47307 in which the EJBContainerImpl was modified to use a different embedded API, specifically, the embedded API that uses DeployerImpl. So even though the output to System.out was there all along, it only started getting used with this revision.

scatari added a comment - 04/Nov/11 09:24 PM

Please review this for potential inclusion into 3.1.2.

Bhavanishankar added a comment - 16/Nov/11 05:56 AM

Assigning to Sakshi

atomicknight added a comment - 11/Oct/12 03:53 PM

Sorry for the extremely delayed feedback, but it looks like the fix committed as r51062 only partially resolves the issue. DeployerImpl contains another print statement in the #undeploy method (line 158 in trunk at r56366), which causes the same problem.

Can this issue be re-opened? Thanks.