Announcement

Collapse
No announcement yet.

Compiler warnings after Java 7_40 update.

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #16
    Originally posted by gkittlaus View Post
    unfortunately I just ran into an issue and I think it miight be related.
    I cannot do any logger operations anymore.



    When I clear my server log, nnothing will happen again anymore. It might be related.
    Are you sure you didn't pause your server log? There's a play/pause button at the bottom. And how do you know that no more entries are being written? Did you try logging something out in a deploy script or something?
    Step 1: JAVA CACHE...DID YOU CLEAR ...wait, ding dong the witch is dead?

    Nicholas Rupley
    Work: 949-237-6069
    Always include what Mirth Connect version you're working with. Also include (if applicable) the code you're using and full stacktraces for errors (use CODE tags). Posting your entire channel is helpful as well; make sure to scrub any PHI/passwords first.


    - How do I foo?
    - You just bar.

    Comment


    • #17
      Nurapley,

      is there any solution for this problem? or do we really have to wait for java 8?

      thx for your reply.

      best regard,

      Comment


      • #18
        Is there a timeline for when the Mirth appliances will be updated with a version of Java 8 to resolve these warnings that show as errors?

        Comment


        • #19
          Java8 Update 20 same error

          I ran in to this issue today. I found this thread and assumed I had Java 7 installed. After comparing 4 different Mirth servers. The other 3 all have Java 6 (U23, U43 and U45) without this problem. The new server that gets this Error/Warning is running Java 8 Update 20.

          Anyone try to downgrade Java 7 (or 8) to version 6 or have another solution for this issue?

          I have Mirth Connect 3.0.3.7171 on the new server and just read the Sticky that indicates Java 8 is supported as of Mirth 3.0.2

          Any other suggestions on how to prevent these errors?
          Last edited by cactuspete; 09-16-2014, 02:07 PM. Reason: read the sticky

          Comment


          • #20
            I read the release notes for Mirth Connect 3.0.2 can't determine how I need to 'update Xstream to 1.4.7' for this issue or if there is something else I should be checking/updating.

            Comment


            • #21
              Mirth Warnings

              I still get the following Mirth Warnings:
              Any responses may be helpful...

              [2014-11-20 10:33:23,387] ERROR (Server:146): Compiler warnings:

              [2014-11-20 10:33:23,309] ERROR (Server:146): Warning: org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser : Property 'http://www.oracle.com/xml/jaxp/properties/entityExpansionLimit' is not recognized.

              [2014-11-20 10:33:23,387] ERROR (Server:146): WARNING: 'org.apache.xerces.jaxp.SAXParserImpl: Property 'http://javax.xml.XMLConstants/property/accessExternalDTD' is not recognized.'

              Comment


              • #22
                Is it possible to suppress this in the log4j config? I don't know which class in the mirth code that the messages are coming from: ERROR 2014-12-17 10:07:40,860 [qtp709531179-2263] Server: Compiler warnings:
                ....

                I don't see a "Server" class in here. If someone can specify which class it is coming from we can just add a rule in log4j.properties to set that one to INFO only. Which might be an issue as we'll be suppressing other ERROR events that we might care about.

                We are on jdk7 u67 so the prior comment that u51 solves the issue is likely incorrect.

                I'd rather not install 6 alongside for mirth as 6 is EOL. We can't exactly move to 3.x and 8 and 3.x is not a drop in upgrade. It's not worth moving heaven and earth to fix this silly error message, but we should be able to do something.

                Is there a better way to fix it? Can we not set those properties that it's saying are not recognized? There should be a simple way around this one.... The oracle bug tracker site isn't working either, what a joke.

                Comment


                • #23
                  Looking through the code it appears these messages are coming from

                  com.mirth.connect.server.logging.LogOutputStream

                  Which somewhat confusingly says: private Logger logger = Logger.getLogger("Server");

                  Server could be a more descriptive string.

                  protected void processLine(final String line) {
                  logger.error(line);
                  }

                  And we see this referenced in:

                  com.mirth.connect.server.Mirth

                  private void initializeLogging() {
                  // Route all System.err messages to log4j error
                  System.setErr(new PrintStream(new LogOutputStream()));

                  So we are teeing system.err with our log4j file. Neat trick. So these messages are in fact coming from somewhere else and dumping to system.err. Which would mean that the real bug here is not with any of the mirth code, but rather xerces, or possibly mirth's use of xerces.

                  Our application is using xerces 2.8 (older) I believe and we do not see this error. I'll try to investigate it from that angle.

                  Any other thoughts anyone? There should be a semi-clean workaround or even fix for this one somehow... It'd be nice if the oracle bug site would come back....

                  Comment


                  • #24
                    I'm seeing this with Java v7 update 75 on Mirth 3.1.1.7461

                    I've heard Java version 8 has it's own bugs. Should I upgrade to 8, or is there another solution?

                    Comment


                    • #25
                      Hello all,
                      I'd like to revisit this issue since the conversation has been quiet here for a month+.

                      Can anyone confirm that an upgrade to Java 8 will fix this issue? We're on 7u60 without any resolution to the server warnings. The warnings are choking our server logs and have caused a heap size issue after letting warnings file to the mirth server log for too long.

                      Are there alternatives to this XmlUtil.prettyPrint that might do the same thing?

                      Our setup: Java 7u60, Mirth Connect 3.2. Warning logs get created during a file writer destination with output template:
                      Code:
                      ${XmlUtil.prettyPrint(${message.encodedData})}

                      Comment


                      • #26
                        We updated our test Mirth Appliance to Java 8u31 this morning and I'm still finding the same errors when the pretty print util is run either from transform or in a file destination template (as posted above).

                        Comment


                        • #27
                          As a workaround, you can suppress the warning from your logs by doing this:
                          • Set "Clear global map on redeploy" to No in the server settings.
                          • Use this in the global deploy script:
                            Code:
                            if ($('log4jFilterSet') != true) {
                            	for (var en = org.apache.log4j.Logger.getRootLogger().getAllAppenders(); en.hasMoreElements();) {
                            		en.nextElement().addFilter(new JavaAdapter(org.apache.log4j.spi.Filter, {
                            			decide: function(event) {
                            				if (event.getLevel().equals(org.apache.log4j.Level.ERROR) && event.getLoggerName().equals("Server")) {
                            					var msg = event.getRenderedMessage();
                            
                            					if (org.apache.commons.lang3.StringUtils.isNotBlank(msg)) {
                            						if (org.apache.commons.lang3.StringUtils.equals(msg, "Compiler warnings:") || org.apache.commons.lang3.StringUtils.contains(msg, "Feature 'http://javax.xml.XMLConstants/feature/secure-processing' is not recognized.") || org.apache.commons.lang3.StringUtils.contains(msg, "Property 'http://javax.xml.XMLConstants/property/accessExternalDTD' is not recognized.") || org.apache.commons.lang3.StringUtils.contains(msg, "Property 'http://www.oracle.com/xml/jaxp/properties/entityExpansionLimit' is not recognized.")) {
                            							return org.apache.log4j.spi.Filter.DENY;
                            						}
                            					}
                            				}
                            				
                            				return org.apache.log4j.spi.Filter.NEUTRAL;
                            			}
                            		}));
                            	}
                            	
                            	$g('log4jFilterSet', true);
                            }
                          Step 1: JAVA CACHE...DID YOU CLEAR ...wait, ding dong the witch is dead?

                          Nicholas Rupley
                          Work: 949-237-6069
                          Always include what Mirth Connect version you're working with. Also include (if applicable) the code you're using and full stacktraces for errors (use CODE tags). Posting your entire channel is helpful as well; make sure to scrub any PHI/passwords first.


                          - How do I foo?
                          - You just bar.

                          Comment


                          • #28
                            What if we still need to ..
                            Clear global map on redeploy

                            with this code does it get cleared?

                            Comment


                            • #29
                              Originally posted by StickyBandit View Post
                              What if we still need to ..
                              Clear global map on redeploy

                              with this code does it get cleared?
                              Then you'll just have to take measures of your own to ensure the filters only get added to each appender once. Otherwise there is potential for a memory leak.
                              Step 1: JAVA CACHE...DID YOU CLEAR ...wait, ding dong the witch is dead?

                              Nicholas Rupley
                              Work: 949-237-6069
                              Always include what Mirth Connect version you're working with. Also include (if applicable) the code you're using and full stacktraces for errors (use CODE tags). Posting your entire channel is helpful as well; make sure to scrub any PHI/passwords first.


                              - How do I foo?
                              - You just bar.

                              Comment


                              • #30
                                What if we still need to ..
                                Clear global map on redeploy

                                with this code does it get cleared?
                                I guess you could flip it and manually clear global variables you're worried about persisting in the global deploy script?

                                As a workaround, you can suppress the warning from your logs by doing this:
                                Set "Clear global map on redeploy" to No in the server settings.
                                Use this in the global deploy script:......
                                Thanks Nick! That looks like it will work for us. It is filtering the warning errors and AFAICT not filtering other server errors unnecessarily.

                                Comment

                                Working...
                                X