PieChart not displaying all entries when there are two 1-count data entries

[stonebranch2]

Hi Isomorphic,

When we have a PieChart with two entries, both with a count of 1, only one of those entries displays in the PieChart, yet both show in the legend.

If I change one of the entries to have a count of 2, rather than 1, or if both have a count of 2, they both display as expected in the PieChart.

SmartClient Version: v12.0p_2019-02-28/Pro Deployment (built 2019-02-28)



Regards


SimpleChartData3

public class SimpleChartData3 extends Record {
    public SimpleChartData3(String sysUpdatedOn, Integer count) {
        setAttribute("updatedOn", sysUpdatedOn);
        setAttribute("count", count);
    }

    public static SimpleChartData3[] getData() {
        return new SimpleChartData3[] { new SimpleChartData3("2019-06-21 (461)", 461), new SimpleChartData3("2019-06-23 (1)", 1),
                new SimpleChartData3("2019-06-24 (18)", 18), new SimpleChartData3("2019-06-25 (1)", 1) };
    }
}

Sandbox9

public class Sandbox9 implements EntryPoint {

    @Override
    public void onModuleLoad() {

        Window window = new Window();
        window.setHeight100();
        window.setWidth100();
        FacetChart chart = getChart();
        window.setTitle("Sandbox9");
        window.addItem(chart);
        window.draw();
    };

    private FacetChart getChart() {
        FacetChart chart = new FacetChart();
        chart.setData(SimpleChartData3.getData());
        chart.setFacets(new Facet("updatedOn", ""));
        chart.setValueProperty("count");
        chart.setChartType(ChartType.PIE);
        return chart;
    }
}

[Isomorphic]

This has been fixed back to SGWT 5.1p/SC 10.1p. The nightly builds dated 2019-06-28 will pick up the changes.

[stonebranch2]

Thank you

[stonebranch2]

Hi Isomorphic,

Thank you for the fix.

One side effect from the upgrade is that we are now seeing unwanted logging appearing in our own log file that never appeared before, and we are not sure why.

2019-07-03-14:56:28:366 -0400 INFO [http-bio-7081-exec-8] IDACall - Performing 1 operation(s)

Can you please help us resolve this, as we need to disable this.

Thank you

SmartClient Version: v12.0p_2019-07-02/Pro Deployment (built 2019-07-02)

[Isomorphic]

That looks like a server-side log, but that's a very old log that has been there literally something like 10 years. Why is it now a problem?

It can be controlled through your log4j XML configuration, like all of our other server-side logs.

[stonebranch2]

We have separate log files, one for isomorphic logging, and one for our own application logging.

With no other change, besides upgrading the libraries from 2019-02-28 to 2019-07-02, those starting appearing in our application log, flooding it.

[Isomorphic]

That log comes from a file (IDACall.java) that hasn't changed in 2 years, 11 months, so this is a bit of a mystery. Also, the log you've shown seems to have been formatted by log4j, which deepens the mystery.

Seemingly the only explanation is that this particular class, and only this particular class, gets a separate instance of log4j which has been configured to just write to system.out (which presumably is where your application log is). The only thing that could explain that is some kind of classloader voodoo where you've got part of our system loaded under one classloader and part under another classloader. This kind of thing can happen if you have duplicates of our .jars in multiple places in the classpath, or have split our jars across two directories that are both in the classpath but are treated differently - ring any bells?

[stonebranch2]

We extend the IDACall class, but that hasn't changed on our end either.

We do not split jars across directories, and no evidence of any duplicate jars in the classpath.

A mystery for us too.

[Isomorphic]

1. This log is in IDACall.processRPCTransaction(). Do you have an override here, perhaps a call to Super?

2. Is there anything special about how your servlet code is loaded - again could be duplicate .jars or class files for your application code, or something like a separate classloader because Spring or some other IOC system is involved. A quick test would be to swap in the standard IDACall servlet and see if the log goes back where the other Isomorphic logs are going

3. Is the format of the log exactly the same as other Isomorphic logs? If it differs, that would serve to confirm that two different log4j configurations are active

4. Finally, you can get have log4j report the complete initialization process logged including configuration source and all the appenders/categories/etc. To enable that set the “-Dlog4j.debug” JVM argument. This might reveal how two different configurations are occurring, eg, you might see your custom IDACall servlet do it's static initialization long before everything else does.

[stonebranch2]

1. We do not override processRPCTransaction.

2. We will do a little testing here when we can.

3. We customize the format, and use a consistent format for both our application log file, and the isomorphic log file.

4. OK

For now we have reverted to the 2019-02-28 build, where we are not experiencing this.

One other thing to note is, that with the 2019-02-28 build, that log message isn't logged into our application log or our isomorphic log, as we set a default log level of WARN for category com.isomorphic.

Thanks

[Isomorphic]

That last tidbit is a pretty clear indication of 2+ log4j configs active.

Just to give you our best guess, after thinking about this further: we set up Log4j in static initializers, and we go through some trouble to try to be first (see server initialization docs). If something you're using (Spring?) manages to initialize before us, and loaded your IDACall subclass, it could end up with it's own log4j setup, and this may even mean multiple instances of our framework classes in memory, under different class loaders.

Our step 4 above should reveal this.

[stonebranch2]

We have determined that a call to LogManager.getRootLogger(), traced back to the com.isomorphic.log.Log4jLogger class in the initRepository method, is the underlying source of the change in behaviour.

It looks likes in the prior build, the call to LogManager.getRootLogger() was not happening here, where as, now it is and that has changed the order in which our "log4j.properties" was read for automatic log4j configuration.

We will look into consolidation of our log4j configuration.

Thanks

[stonebranch3]

Hi Isomorphic,

After taking a closer look at this, the problem is due to Log4jLogger using the LoggerRepository from the RootLogger configured by log4j.xml (default initialization procedure). The Log4jLogger used to use its own unique LoggerRepository configured by log4j.isc.config.xml but this changed sometime after 2019-02-28.

We have tested this using the following custom InitListener to temporarily change the LoggerRepository during initialization and this restores the previous behavior.

public class TestInitListener extends InitListener {

    public TestInitListener() {}

    @Override
    public void contextInitialized(ServletContextEvent event) {
        LoggerRepository origRespository = LogManager.getLoggerRepository();
        Hierarchy h = new Hierarchy(new RootLogger(Level.WARN));
        LogManager.setRepositorySelector(new DefaultRepositorySelector(h), null);
        super.contextInitialized(event);
        LogManager.setRepositorySelector(new DefaultRepositorySelector(origRespository), null);
    }
}

Thanks

[Isomorphic]

Is this a bug report? It's not clear if you are using our InitListener as the docs state, or whether you are now trying to initialize things before or after us? After is what we recommend.

[stonebranch3]

Yes, this is a bug report. The code provided was just used to illustrate that the com.isomorphic.log.Log4jLogger is using the RootLogger configured by log4j.xml instead of creating its own in the initRepository method.

Specifically, the initRepository method used to set the repository to the following:

hierarchy = new Hierarchy(new RootLogger(log4jLevel));
repository = hierarchy;

However, it now sets the repository to the following:

repository = LogManager.getRootLogger().getLoggerRepository();

Thanks