Closed adriandeleon closed 1 year ago
Thanks for reporting this issue. I will look into it soon and keep you updated.
As for Lombok, I have not yet tested it and I guess there's the possibility that sometimes it intereferes, but I don't think it's the issue here.
I was able to reproduce the issue with version 0.1.2 but not with the latest commit version. I've released 0.1.3 on Maven and it should be available in a few hours (or you can clone the repo). As I am not sure about the cause of the issue yet, please let me know if still persists on your end.
I get the same problem with 0.1.3. My entity setup is really simple:
@Entity
@Table(name = "users")
public class ChatUser {
No lombok is involved.
Just noticed I'm using OffsetDateTime
which isn't in your list of supported types.
Hey @agxs, thanks for chiming in!
Using an unsupported type should result in an error at startup, like the following:
tech.ailef.dbadmin.external.exceptions.DbAdminException: Unable to determine fieldType for class java.time.OffsetDateTime
Since this is not happening it means the "Not a managed type" error occurs earlier and is not related to the OffsetDateTime
. In other words, you would get the OffsetDateTime
error anyway after fixing the first one.
Could you tell me what is your data source and how it's configured?
PS: I can look into adding OffsetDateTime
support as well, I'll open another issue about it (#7).
In particuar, could anybody who is getting this error look at the application.properties file for the test project and see if there's any possibly relevant difference, particularly in regarding the way the data source is set up?
Running in the debugger it looks like the list of managed entities stored in the JPA Metamodel and the class passed via the CustomJpaRepository
aren't equal (despite being the same package and classname). Looks like the registered classloader for each Class
is different.
Not sure the above is relevant after following through other sections of the code :(
Thanks for the quick response @aileftech . My application.properties
setup is:
spring.datasource.driverClassName=org.postgresql.Driver
spring.datasource.url=jdbc:postgresql://localhost:5432/<db>
spring.datasource.username=<username>
spring.datasource.password=<password>
spring.flyway.url=${spring.datasource.url}
spring.flyway.user=${spring.datasource.username}
spring.flyway.password=${spring.datasource.password}
spring.flyway.baseline-on-migrate=false
spring.jpa.open-in-view=false
spring.jpa.properties.hibernate.dialect=org.hibernate.dialect.PostgreSQLDialect
I think I have found the issue, or at least I have an idea on how to investigate. Could you please add the property:
dbadmin.testMode=true
and see if it runs? The difference is that it will use an in-memory database for the internal storage, so it will not persist across restarts. A problem occurs when the persistent data source is used instead, if my intuition is correct.
In any case I am able to reproduce the issue now with the latest version as well so I'll be working on it.
Upon further inspection, this seems to have nothing to do with testMode
, but rather with the way the library is loaded. It works when I run from the IDE with a not yet mvn install
ed version of the library. At this point it doesn't work from the command line with mvn spring-boot:run
because it doesn't find the dependency. After mvn install
it runs from the command line but gives the exception.
Could this be the ClassLoader related issue you where mentioning? Not asking rethorically, I don't know much about that.
I believe I have finally solved this issue.
The problem is the inclusion of spring-boot-devtools I had in my pom.xml
. When using Devtools there's a custom RestartClassLoader to perform live-reloading. This results in the EntityManager and the Entity class having a different ClassLoader and thus the EntityManager not recognizing the entity as a managed type. I'm not sure why this happens only when using the command line (when using the IDE both classes have the same RestartClassLoader).
In any case, the solution for now is to not include devtools. I've removed it from my pom.xml
and you should remove it from yours as well in order for the application to run.
If anybody can confirm this solves the issue it would be great. I'll open another issue in order to see if I can work around this problem and make the project work with Devtools as well.
I have released a fixed 0.1.4
version on Maven which should be available soon. Waiting for some feedback to mark the issue as closed.
I just saw your #8 issue and remembered I have the Spring DevTools artifect loaded in my project. Removing this dependency worked (Well, now I get the error about OffsetDateTime
not being recognised but that's covered in #7 😄 )
EDIT - ah yes, just noticed your update above, my browser tab hadn't updated when I added this comment.
Thank you so much! I'm glad it works now, as this one was a bit tricky to debug (GPT4 has been very useful to troubleshoot with).
I'm already working on OffsetDateTime
as well, but it requires a bit of a refactor for the code to be more flexible so I can also add other types later more easily.
Hello, I'm getting a java.lang.IllegalArgumentException: Not a managed type: class com.grokthecode.damcheck.entities.DamEntity Exception for a entity named DamEntity, but it does have the @Entity annotation.
Here is the relevant stack trace:
And here is the partial code for the entity:
I am using Lombok, maybe that's causing noise?
I'm using Spring boot 3.1.4, Amazon Correto JDK 17 and spring-boot-database-admin 0.1.2
Thank you.