Skip to main content

Disabling reporting output when running embedded Glassfish?

Please note these forums are being decommissioned and use the new and improved forums at
2 replies [Last post]
Joined: 2010-03-14


I have a command-line-based application that uses the embedded Glassfish runtime (via javax.ejb.embeddable.EJBContainer#createEJBContainer) to compute some values and print them to stdout so that they can consumed by other programs. With Glassfish 3.1, this worked perfectly well because the container did not print anything directly to stdout (i.e. the only messages that were printed were log messages that could be redirected elsewhere). However, Glassfish 3.1.1 now prints some diagnostics information whenever the application is deployed - this obviously breaks the functionality of my existing application. Specifically, the output looks like this (the ellipses indicate where the computed values are printed):

<div>PlainTextActionReporterSUCCESSDescription: deploy AdminCommandApplication deployed with name embeddable.</div><div>    [name=embeddable</div><div>....</div><div>PlainTextActionReporterSUCCESSNo monitoring data to report.</div>

Is there any way of disabling or redirecting this output? While this information may be useful, I think it'd be preferable to have it generated as part of the logs rather than printed directly to stdout.

Thanks in advance!

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
Joined: 2005-10-31

The output is coming from the following line in (line


Would you like to file a JIRA issue on this? I would think that the
embedded APIs shouldn't be writing anything to System.out.

What is mysterious is that this line has been there all along, even in
3.1. So I don't see why you didn't see the output with 3.1.


Joined: 2010-03-14

Hi Tom,

Thanks for the prompt response. I had tried tracking down the cause of the error myself and couldn't figure out what exactly changed to cause that information to be printed; as you've noted, the line that actually performs the printing has been there for a long time. I did manage to narrow it down to something between 3.1.1-b06 and 3.1.1-b07, so hopefully it'll be a bit easier to diagnose given that information.

The JIRA issue (including a test case) is now here: