FYI: Generating ebean.mf and generating code to register entity classes

[Rob Bygrave]

META-INF/ebean-info.mf

I'll shortly be pushing an enhancement to the querybean generator (Java & Kotlin) such that they generate a META-INF/ebean-info.mf manifest file (which means we won't need ebean.mf).

This ebean-info.mf will contain the entity-packages and will effectively mean that we will no longer need the ebean.mf file (unless we want to customise advanced enhancement settings).  

ModuleInfoLoader (to automatically register entity classes)

Along with this the querybean generators will generate a class that implements a new interface called ModuleInfoLoader.  This will explicitly list the entity bean classes that should be registered with the default DB and other named databases (such that we don't have to write that manually or use classpath scanning to find them).

We will be able to turn this on and off.

This will generally be very good as it means people will get fast startup with no effort as there isn't any need to scan for entity classes etc or write code to explicitly register the entity classes. 

However, this might lead to confusion if applications are using classpath scanning to register classes that are not entity classes but also extension interfaces like BeanPersistController, BeanPersistListener, BeanQueryAdapter etc. 

Those applications needing and wanting classpath scanning for this need this off.  Initially it will be off by default but I suspect that 99% of applications should have this turned on.

Any application that adds classes to ServerConfig/DatabaseConfig isn't using classpath scanning.

I hope to get this right and not cause confusion for apps using classpath scanning.

Cheers, Rob.

[Rob Bygrave]

Update to note that 12.1.8 included these changes.  The manifest file generated by the querybean-generator is actually:

 META-INF/ebean-generated-info.mf  

Again this means that we can do away with ebean.mf.  People using 12.1.8+ don't need a ebean.mf file.

We have not "turned on" automatic use of ModuleInfoLoader but I'm pondering if we can do that in version 12.2.1 (I'm leaning towards turning it on in 12.2.1).

[Jens]

Just upgraded to 12.1.9 and the generated _ebean$ModuleInfo class is stored in package "unknown". I guess the package name is a fallback because if could not be computed. 

Any idea? The base entity has @DbName annotation and the generated class seems correct, except the package name.

Note: Ebean APT generated 8 query beans, loaded 0 others - META-INF/ebean-generated-info.mf entity-packages: [xxxxx.app.entities]
warning: File for type 'unknown._ebean$ModuleInfo' created in the last round will not be subject to annotation processing.
1 warning

Also the warning might be avoidable.

-- J.

[Jens]

Just noticed:

https://github.com/ebean-orm/querybean-generator/blob/master/src/main/java/io/ebean/querybean/generator/ProcessingContext.java#L382

The method addEntity does never call updateFactoryPackage() if we have a dbName for all entities added, thus the final package name will be "unknown" since it was never set.

--- J.

[Rob Bygrave]

Right.

As a side point can you describe why all the entities have a @DbName ?  ... As to me that implies there is no "default database".  Can you outline the scenario where an application doesn't have a default database?  

--

---
You received this message because you are subscribed to the Google Groups "Ebean ORM" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ebean+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ebean/ab60e23d-2b56-4e66-b9aa-da8da3793482%40googlegroups.com.

[Jens]

As a side point can you describe why all the entities have a @DbName ?  ... As to me that implies there is no "default database".  Can you outline the scenario where an application doesn't have a default database?  

Of course each web app has its own database which would be the default database but if you share entities between apps you still need to be explicit about the db name so that each entity "belongs" to the correct database. Otherwise the "default" database the entity is attached to would change when using the entity in different apps.

As an example:

A.) A tenant based app wants to lookup some tenant configuration in an administrative database

B.) A administrative app executes administrative tasks in all tenant databases

-- J.

[Rob Bygrave]

Yes, makes sense, thanks.

>  if you share entities between apps

My personal thought is that to me it seems we developers often under utilise "traditional modular development" and sharing code across apps (without the network costs, complexities, distributed monolith foo).  The current Ebean documentation doesn't talk about this anywhere and we should really discuss it somewhere - "techniques when sharing entity model across apps".

Hmmm.

Additionally, Postgres especially has the potential to make "logical replication" a more common design choice and that would also naturally involve sharing entity models across applications - we don't talk about how that is best done either.

Cheers, Rob.

--

---
You received this message because you are subscribed to the Google Groups "Ebean ORM" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ebean+un...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/ebean/1435c797-436e-4480-9fa6-e33c0e087d68%40googlegroups.com.