Specialized IT Services focused on Data Management | Speak with Us 877-634-9222
Art of BI: WebLogic Log Repeats OpenJPA will not be used – Solution
WebLogic Server is probably one of the best JEE Application Servers on the market but it is not without quirks as with any other software. We found one annoying quirk/bug for which we just had to showcase a solution.
BITeamwork utilizes JPA technology to interface the application against the database metadata repository it communicates with to store its comments, annotations, and other collaborative BI information. JPA is really cool and makes programming efforts much easier when accessing databases especially when supporting multiple RDBMS technologies. When deploy BITeamwork to WLS (problem doesn’t exist when deployed to IBM Websphere) the WLS standard out/error (stdout/stderr) log for the Managed Server on which it is deployed constantly prints the following log message:
INFO: Found persistence provider "org.eclipse.persistence.jpa.PersistenceProvider". OpenJPA will not be used.
Although this redundant logging in no way affects the functionality of WebLogic, Oracle BI or BITeamwork it is somewhat annoying.
Again this is an issue with the WLS server which has been documented in a few Oracle Support tickets (ID 1465271.1, 1058474.1 and 981264.1) with ID 1465271.1 being the most relevant. What’s stranger is that even though this is an INFO stdout message from WLS it gets generated under stderr output which is clearly a bug in WLS logging. You would only know or see this subtle difference if you adjust the WLS logging and enable standard out redirect show for that managed server.
Oracle provides no direct step-by-step instructions in those support tickets, only a statement declaring that this issue is fixed/resolved in WLS versions subsequent to 10.3.3. This is not a true statement from Oracle as the issue persists in version 10.3.5 and 10.3.6.
The steps below show the manual way to achieve filter or removing this message from the log files which we recommend if it becomes an annoyance. There is the ability to use WLST to filter out this message but it is best to be as transparent as possible in a situation such as this one and just go manual.
To relive your log files from growing largely with superflous messages of this nature, WLS offers a feature called Log Filtering. This is a great concept as it allows your standard out or standard error messages from any of your deployed applications to simply be ignored. Technically you’d want to have isolated the output message and understand exactly the meaning and the purposes of the message before hiding it, but once that is done, as we have in this case, you can simply create a log filter to safely ignore the message. To do this follow the instructions below.
- Log in to your WLS Admin Console
- Click on the Domain Name
- Under the Configuration main tab, click the Log Filters sub-tab
- Click on the New button in the Log Filters sub-tab.
- In the Name textbox, enter Filter Out Open JPA INFO.
- This will give the filter an alias that we will use later.
- Click the OK button and you’ll return to the Log Filters tab section.
- Click on the newly created Log Filter record, Filter Out Open JPA INFO, to begin editing its logic.
- Click the Edit button to begin inputing logic for this particular filter.
- Enter the following logic and then click the OK button,
- NOT(MESSAGE LIKE ‘%OpenJPA will not be used%’)
- Click the Save button on the Configuration tab to save the filter expression. Messages will appear at the top of the page telling you if you’ll need to restart any services or not before using the log filter. If so, please follow those instructions before continuing.
- Click Environment > Servers > bi_server1 (or other Managed Server), on the left-navigation pane to navigate to Managed Server location where the JEE application which is causing the message to be generated so that it can be edited.
- Click the Logging main-tab tab and click the General sub-tab
- Click the Advanced section at the bottom to expand more options for logging
- Under the Standard out: section, use the dropdown menu for the Filter to select the new Log Filter alias that you created in the previous steps…
- Check the checkbox for the Redirect stderr logging enabled so that the reference to use the log filters is recognized by WLS (this option from testing seems to be a requirement but no further WLS documentation on the true relationship is available). This is slightly above the area where you conducted the previous step.
- Click the Save button at the bottom of the page.
- Restart your managed server (or you might as well bounce WLS if you want to be truly thorough) so that the changes can take place if any message prompt you at the top of the page after you’ve saved your logging adjustments.
After your WLS Application Server restarts you will see that upon using the BITeamwork application the aforementioned logging message no longer appears, thus less clutter in our log files.
This concept can be applied to many Oracle BI situations as the log files can get quite verbose and if your team members are sticklers for clean logs, code, and design then this may be an option for your other pesky logging concerns.