Issue #2412: Enhancement Check

Hello,

is there any possibility for a check whether all entities are already enhanced within a jar file?

We got following exception although we think all entities are enhanced:

Caused by: com.objectdb.o.UserException: Too many persistable types (>10) - exceeds evaluation limit
        at com.objectdb.o.MSG.a(MSG.java:64)
        at com.objectdb.o.MST.Z2(MST.java:1145)
        at com.objectdb.o.WRA.Z2(WRA.java:215)
        at com.objectdb.o.TYS.e(TYS.java:769)
        at com.objectdb.o.TYS.Z5(TYS.java:593)
        at com.objectdb.o.TYM.Y(TYM.java:554)
        at com.objectdb.o.TYM.<init>(TYM.java:195)
        at com.objectdb.o.OMF.v(OMF.java:844)
        at com.objectdb.o.OMF.r(OMF.java:796)
        at com.objectdb.jpa.EMF.r(EMF.java:130)
        at com.objectdb.o.OMF.w(OMF.java:694)
        at com.objectdb.jpa.EMF.createEntityManager(EMF.java:149)
        at com.btc.ep.base.dal.internal.repositories.OdbPersistenceManagerImpl.triggerODBIndexActivation(OdbPersistenceManagerImpl.java:550)

best regards

BTC

Enhanced classes implement the interface com.objectdb.spi.TrackableUserType.

OEM Enhanced classes implement also the interface com.objectdb.spi.SignedType.

So you can check if an entity classes is OEM enhanced by:

    MyEntityClass instanceof com.objectdb.spi.SignedType

Hello,

thank you for the hint, it performs.
But we figured out that all classes are enhanced correctly.

Which other reasons can cause the exception. Maybe old deprecated entity classes which are persisted in the database, but this ones are removed and don't exist anymore in our jars?
Or other reasons?

best regards
BTC

> Maybe old deprecated entity classes which are persisted in the database, but this ones are removed and don't exist anymore in our jars?

This could be possible as missing classes are replaced by ObjectDB with synthetic auto generated classes, which are not signed and may be counted against the 10 classes limit. Do you have more than 10 obsolete classes? If you can verify that the exception is only thrown when an old database with obsolete classes is accessed then we can look for a solution for this specific possible issue.

> Or other reasons?

Nothing that we are aware of.

Thank you for your answer. Is there any way to retrieve a list of the classes which are not enhanced / missing classes? Unfortunately, the database is rather large and we cannot comb through it manually.

We do know however, that the error is gone, if we create the database from scratch with only enhanced entities. 

Please try build 2.7.6_03 that excludes old classes from licence checks.

Hello again,

build 2.7.6_03 fixes the issue.

Thank you very much for your help!

Hello,

we got another case with the same issue.

It is possible to find out which entities are responsible for the limitation exception?

best regards
BTC

Logging was now added in build 2.7.6_05.

Enable it in the ObjectDB configuration file:

     <logger name="type" level="debug" />

and the names of the classes will be written to the ObjectDB log file when the exception is thrown.

The logging performs, thanks.

But every entity class which cannot be found by classloading was created as synthetic class by ObjectDB. And I thought this kind of entities are ignored in the license check.

I would like to provide the objectdb log file, but unfortunately the attachment upload didn't work.

All the entity classes in these new log messages are considered by ObjectDB as not synthetic, i.e. apparently ObjectDB found real classes in the classpath for them (unless there is an unexpected behaviour) .

Sorry, now I am rather confused. I've found in the log:

[2019-03-19 13:08:12 #1 type.loader]
java.lang.ClassNotFoundException: com.btc.ep.engine.bl.dmos.VectorResult
...

[2019-03-19 13:08:12 #2 type.loader]
java.lang.ClassNotFoundException: java.lang.com.btc.ep.engine.bl.dmos.VectorResult
...

[2019-03-19 13:08:12 #3 type.loader]
Building a synthetic Class for com.btc.ep.engine.bl.dmos.VectorResult
 

Does this not mean that ObjectDB has generated a synthetic class for VectorResult in both cases?

Can you maybe provide more insight into this topic so I can try to fix the issue on my side?

> Does this not mean that ObjectDB has generated a synthetic class for VectorResult in both cases?

After two attempts to load the class that failed the class is generated synthetically once.

Do you see that specific class also in a log message in the form (starts with "Entity Class")?

    Entity Class: java.lang.com.btc.ep.engine.bl.dmos.VectorResult

You should see in the log file more than 10 "Entity Class: " entries, non of them should be reported as synthetic class, so java.lang.com.btc.ep.engine.bl.dmos.VectorResult should not appear in such "Entity Class: " log entry.

Unfortunately we didn't see any log entry "Entity Class: ".

But the log entries as described above.

Could you please try the following console test?

(it should show the new log entries if the new logging is enabled, the new build is used and there is no valid activation code on the machine.)

import javax.persistence.Entity;
import javax.persistence.EntityManager;
import javax.persistence.EntityManagerFactory;
import javax.persistence.Persistence;

public class F2412 {
    public static void main(String[] args) {
        EntityManagerFactory emf = Persistence.createEntityManagerFactory("objectdb:test.tmp;drop");
        EntityManager em = emf.createEntityManager();

        em.getTransaction().begin();
        em.persist(new E1());
        em.persist(new E2());
        em.persist(new E3());
        em.persist(new E4());
        em.persist(new E5());
        em.persist(new E6());
        em.persist(new E7());
        em.persist(new E8());
        em.persist(new E9());
        em.persist(new E10());
        em.persist(new E11());
        em.getTransaction().commit();

        em.close();
        emf.close();
    }
    
    @Entity static public class E1 {}
    @Entity static public class E2 {}
    @Entity static public class E3 {}
    @Entity static public class E4 {}
    @Entity static public class E5 {}
    @Entity static public class E6 {}
    @Entity static public class E7 {}
    @Entity static public class E8 {}
    @Entity static public class E9 {}
    @Entity static public class E10 {}
    @Entity static public class E11 {}
}

Do you get the "Too many persistable types (>10)" exception with no "Entity Class: " messages in the log, when you use build 2.7.6_05 and <logger name="type" level="debug" /> is set in the correct configuration file?

Exception in thread "main" com.objectdb.o.UserException: Too many persistable types (>10) - exceeds evaluation limit
    at com.objectdb.o.MSG.a(MSG.java:64)
    at com.objectdb.o.MST.Zv(MST.java:1145)
    at com.objectdb.o.WRA.Zv(WRA.java:215)
    at com.objectdb.o.TYS.e(TYS.java:769)
    at com.objectdb.o.TYS.Zy(TYS.java:593)
    at com.objectdb.o.TYM.Y(TYM.java:554)
    at com.objectdb.o.TYM.j(TYM.java:489)
    at com.objectdb.o.TYM.R(TYM.java:824)
    at com.objectdb.o.TYM.Q(TYM.java:909)
    at com.objectdb.o.TYM.K(TYM.java:981)
    at com.objectdb.o.OBM.aO(OBM.java:384)
    at com.objectdb.o.OBM.aO(OBM.java:270)
    at com.objectdb.jpa.EMImpl.persist(EMImpl.java:415)
    at smallTests.F2412.main(F2412.java:29)

Sorry, there seems to be some "internal server errors" on your forum... Trying again:

Good Morning,
first of all thank you for your kind help and fast replies. We have now tried various things, but are not any wiser.

Running your code yields the usual error:
Exception in thread "main" com.objectdb.o.UserException: Too many persistable types (>10) - exceeds evaluation limit
    at com.objectdb.o.MSG.a(MSG.java:64)
    at com.objectdb.o.MST.Zv(MST.java:1145)
    at com.objectdb.o.WRA.Zv(WRA.java:215)
    at com.objectdb.o.TYS.e(TYS.java:769)
    at com.objectdb.o.TYS.Zy(TYS.java:593)
    at com.objectdb.o.TYM.Y(TYM.java:554)
    at com.objectdb.o.TYM.j(TYM.java:489)
    at com.objectdb.o.TYM.R(TYM.java:824)
    at com.objectdb.o.TYM.Q(TYM.java:909)
    at com.objectdb.o.TYM.K(TYM.java:981)
    at com.objectdb.o.OBM.aO(OBM.java:384)
    at com.objectdb.o.OBM.aO(OBM.java:270)
    at com.objectdb.jpa.EMImpl.persist(EMImpl.java:415)
    at smallTests.F2412.main(F2412.java:29)
    
The log file does indeed show the "Entity Class: "... messages, as you may or may not see from the attached log (Did you actually receive the log file? The "Files add" button does not report this properly...)

We have also tried to write a small program to reproduce our issue, but without any luck. We open a database from our production code and with the older objectdb versions we see the evaluation limit error (as expected). Using the latest objectdb version, the error is gone (Which is what we want to achieve). We still have this error in our (more complex) production code, though.

What we do there is the following:
We don't ship an objectdb licence key to the customer, but instead enhance all classes that we provide. Now the customer may create a database using the "full" version of our tool. He then switches to another licence model of our tool, with a reduced feature set. In this version, we do not install / provide all classes, but a limited set. When the customer tries to open the database, we get the evaluation limit error.

Hello again,
we have now checked a bit further and can confirm that 2.7.6_05 fixes the issue!
The remaining problems were fixed by performing a proper build of our product.

Thanks for your patience and help.

Thank you for the update.

> we have now checked a bit further and can confirm that 2.7.6_05 fixes the issue!
> The remaining problems were fixed by performing a proper build of our product.

2.7.6_05 just adds new logging entries (hope it helped if fixing your build). Ignoring old unused classes (synthetic) was added in 2.7.6_03. Good to hear that it works now.

> I would like to provide the objectdb log file, but unfortunately the attachment upload didn't work.

> Did you actually receive the log file? The "Files add" button does not report this properly...

There is a new issue in uploading files, we will investigate it. Thank you for this report.

Support of uploading attachments to posts has been fixed. Thank you for this report.