Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

TypeProviderFor(MybatisMapper.class) not registering mapper #4

Open
swalton00 opened this issue Mar 17, 2022 · 19 comments
Open

TypeProviderFor(MybatisMapper.class) not registering mapper #4

swalton00 opened this issue Mar 17, 2022 · 19 comments

Comments

@swalton00
Copy link

I am converting from Grovvy/JavaFX to pure Java/Swing (and upgrading to the current Griffon version at the same time). I am using the MyBatis plugin and getting all the way to DatasourceConnectEnd, but the mapper is not registered. The Mapper is coded as:

@TypeProviderFor(MybatisMapper.class)
public interface DBMapper extends MybatisMapper {

I have looked in the targets/classes/META-INF directory and there is no "types" directory in the Java version (but there is in the Groovy version, and it has MybatisMapper in it.

Is this a bug, or is there something else I need to do to register the mapper.

@swalton00
Copy link
Author

IntelliJ wasn't configured to use gradle and that skipped annotation processing. Even fixing that did not resolve the issue. Running Gradle 5.4.1 with Azul 11.0.14 on Windows 10
Annotation processing is running (verified by putting a typo in the annotation -- it detects the error)., but mapper is not registered. And no folder for "types" in target/classes/META-INF

@swalton00
Copy link
Author

I was (finally) able to get the Maven build almost working, but got the same error - DBMapper is not known to the MapperRegistry. I've looked through the source and the only way to register it is to extend the DefaultMybatis-Handler to call my own DefaultMybatisFactory.

@aalmiray
Copy link
Member

You're probably missing the annotation processor settings. Make sure jipsy is configured.

@swalton00
Copy link
Author

It was not configured in the new (basic empty Griffon), either in Gradle or Maven. I added it and another piece (earlier in the configuration) stopped working. I have a "MutableDataSource" that provides the database information from other stored data. A DataSourceEvictionModule evicts the old DataSource to replace it. With jipsy configured, those bindings don't seem to get looked at, so the module was never replaced.

@aalmiray
Copy link
Member

I think it would be a good idea if you post a link to a reproducer project.

@swalton00
Copy link
Author

I added in the jipsy to dependencies in gradle, setup the configuration so it will load the database information from DataSource.java. It still fails on not finding the Mapper.

@swalton00
Copy link
Author

I have another project that will do that: https://github.com/swalton00/RRTools the branch "rewrite_in-Java" has the problem and should come up to trying the database. I set the properties file to use an H2 in memory (empty) database so queries won't actually work.

@swalton00
Copy link
Author

I built a test app with Groovy and that runs fine. Then I built a test app with Java and that fails with the error. I have invited you to collaborate on a private Github project (https://github.com/swalton00/Griffon_failure) with that code. You will also find a "Problems.txt" file with a list of all the issues I find getting it to work.

@aalmiray
Copy link
Member

I'm able to reproduce the problem. For some odd reason the @TypeProviderFor annotation is not working with Java code. However, it's possible to make the mybatis handler work by explicitly registering the type in the expected location. The annotation processor's job is to write said file for you.

META-INF/types/griffon.plugins.mybatis.MybatisMapper

com.spw.test.LocalMapper

@swalton00
Copy link
Author

I have successfully managed to get the demonstration code to process the Mybatis file correctly. The workaround will be okay, but it certainly is not a permanent fix (it won't survice a clean).

After all this looking at the DefaultMybatisHandler, I'm going to checkout a copy of the Mybatis plugin and add change a couple of items. I've never been comfortable returning a String out of the handler and, especially with Java, the workarounds are rather nasty looking. I want to change that to returning an Object instead. Also I want to expose the SqlSession, one for AutoCommit on, and one with it off. There are a number of problems that are best solved with a Transaction (and none involve a user interaction in the midst of a Transaction!)

@aalmiray
Copy link
Member

It does survive a clean if you put the file inside 'src/main/resources`.

@swalton00
Copy link
Author

It looks as if all the build information is contained in a plugin, which I think is in your Maven local:


buildscript {
    repositories {
        gradlePluginPortal()
        mavenLocal()
    }
    dependencies {
        classpath "org.codehaus.griffon:griffon-plugin-gradle-plugin:$griffonVersion"

    }
}
apply plugin: 'org.codehaus.griffon.plugin'

rootProject.name = 'griffon-mybatis-plugin'

Is there any chance of getting a copy of the plugin?

@swalton00
Copy link
Author

I should also mention that, once I have this working, I will submit a Pull Request and you decide if you like the changes, or want me to change something. I plan to change only the DefaultMybatisHandler, the Interface that describe it and the documentation. My plan is to change the String return on the withSqlSession to an Object (after all a List is an object as well), and to add two method calls: getSqlSession(String sessionFactoryName) and getSqlSession(String sessionFactoryName, boolean autoCommit). In the documentation, I will give examples of use of each of those. The autoCommit example will be to add a row to a person table, which also has a required (one or more) addressess. The insert of the Person table will be in a transaction with the insert to the Address table -- if one succeeds, they both succeed -- if one fails, they both fail. A commit follows, with all inside a try....finally block (to release the SqlSession. The session can be garbage collected after the commit occurs.

@swalton00
Copy link
Author

I do need one more method for session close,

@aalmiray
Copy link
Member

Be aware that the plugin's code expects Griffon 3.x. You'll have to find a commit that's compatible with 2.x and create a branch.

@swalton00
Copy link
Author

You are referring to the Gradle plugin, rather than the Mybatis plugin to Griffon (the last commit on the Mybatis plugin was March of 2021). Is the Gradle plugin on github and does it have a Git history that would include a 2.x compatible branch?

@aalmiray
Copy link
Member

Yes, I'm referring to the mybatis plugin. The Griffon gradle plugin is available from Griffon's repository, on branch development_2_X.

@swalton00
Copy link
Author

I think I have it

@swalton00
Copy link
Author

swalton00 commented Oct 11, 2022 via email

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants