[GLASSFISH-17417] Embedded Glassfish is hard-coded to print reporting output to stdout Created: 12/Oct/11  Updated: 11/Oct/12  Resolved: 22/Nov/11

Status: Resolved
Project: glassfish
Component/s: embedded
Affects Version/s: 3.1.2_b01
Fix Version/s: 3.1.2, 4.0

Type: Bug Priority: Major
Reporter: atomicknight Assignee: sakshi.jain
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Java 6u27


Attachments: Zip Archive EmbeddedTest.zip    
Tags: 3_1_2-review, embedded

 Description   

Original forum thread: http://www.java.net/forum/topic/glassfish/glassfish/disabling-reporting-output-when-running-embedded-glassfish

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.



 Comments   
Comment by Tom Mueller [ 13/Oct/11 ]

The output is coming from the following line in DeployerImpl.java (line
134):

actionReport.writeReport(System.out);

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.

Comment by scatari [ 04/Nov/11 ]

Please review this for potential inclusion into 3.1.2.

Comment by Bhavanishankar [ 16/Nov/11 ]

Assigning to Sakshi

Comment by atomicknight [ 11/Oct/12 ]

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.

Generated at Sat Feb 28 13:23:54 UTC 2015 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.