Import Nullpointer Exception

[jabo59]

Hi Hervé,

when I try to import model elements from the DB a nullpointer exception occurs (cannot import model). My problem is it worked last week and I didn't change things (no updates). I'm using plugin version 2.2.19 and Archi 4.8.1.

The silly thing: Whne I create a new model and try to import, it works. How can I figure out, what's wrong with the other model? Any help is appreciated. Thanks and ...

Best regards,
Jakob

[herve91]

Hi Jakob,
Please switch the plugin's log to trace mode and provide me with the Java exception and few lines before that I can understand what happens.
Thanks
Hervé

[jabo59]

Hi Hervé,

I switch the logger to expert mode including sql statements. This is the log. I'm not sure if this is the trace mode. How can I switch the plugin to trace mode. But I see that only the import of components runs into the null point exception.
DatabasePlugin.log

[herve91]

Hi,
You must activate the trace mode. The easiest way is to be in simple mode and you just need to select "trace" (the "include SQL requests" should be selected by default):

[jabo59]

Thanks Hervé. Voila. Here is the database log.

Kind regards,
Jakob
DatabasePlugin.log

[herve91]

Hi Jakob,
I'm sorry but the log file does not contain the Java Exception with the location where the exception arises. Did you edit the file before sending it ?

[herve91]

Just few precisions ...

I did some testing with Archi 4.8.1 (build 202101181039) and my plugin version 2.2.19 and couldn't reproduce your error. So without the Java exception that gives the java filename and line where the error arises, I won't be able to fix it.

[jabo59]

Hi Hervé,

I will test it again today. I didn‘t make a change to the log.

[jabo59]

Hi Hervé,

new information. I figured out the following aspect: The source model has under Views a folder structure. When export and import (force shared mode), the folder structure is not transferred to the target model (I guess it's not part of the export). All views are on level right below Views, When I rebuild the folder structure and move the views in the approbiate folders everything is still working as expeted. But when I rename a view in the target model the next "import components" crashes. The log has now included the crash. I don't know why it was not part of the former log. But here it is. So my cnclusion is right now:

1. If a different view is the cause of the crash is it possible to fetch this error and produce a "readable" error message?
2. There should be a hint in the doks that renaming of components is not a idea and will create "special" situations. Is it possible to do the import only based on the components id?
3. I would appreciate if folder structure in every area can be preserved during export/import. Maybe with a switch so that the user can decide if wants to keep the folder structure.

While I'm not a Java programmer I cannot check or extend the java code. Sorry.

Kind regards,
Jakob

[herve91]

Hi Jakob,

The new log file you send does contain the Java exception. The error is located in file DBChecksum.java line 125. Now I can investigate to understand why the checksum calculation fails ... I'll come back to you asap.

Regarding your other points:

When you export a model, the folders are exported ... so when you import a model, then it is imported with all the folders structure.

Individuals components can be included in several models, and be located in different folders across all these models. That's the reason why when you import a component from the database, it does not come with any folder information.

If you import a component with a right click on a folder, then it is imported in that folder. Alternatively, when you import it from the menu (or if the component class is not compatible with the folder) then it is created in its default folder.

Best regards
Hervé

[jabo59]

Hi Hervé,

thanks for your support. Regarding the folder structure: When I export the model, the folders I've created were not exported. So after import I have a flat structure below the standard folder "Views". When I do the import of elements with right click, it works like you described.

Best regards,
Jakob

[herve91]

When you export the database, the folders structure is definitively exported and imported back.

In some situations, when database issues arise during an import, a pop-up gives the choice to cancel the import or to keep the model imported even if it is not consistent ... May be this is something which happened to you ?

[herve91]

Here is my investigation result from your log file.

• In an existing model you imported the view "Prozess_Einreise_Aktuell" from an sqlite database.
• You choosed to import the view in shared mode, which means that the imported components will keep their technical IDs and then, if you update them and export them back to the database, all the models that include those components will get your updates.
• The plugin imported the view
• And recursively imported as well all the components (objects and relationships) that are present in the view
• At this stage, the view import process states that the view has been correctly imported and no error has been raised
• you closed the import window

Then, you wanted to import another component:

• you selected "import component from database" menu
• part of the process, the plugin calculates checksums on your existing model components to know if you've got the latest version of them or if the database contains more recent versions.
• during this process, the plugin fails to calculate the checksum for one component and raises a Java NullPointerException.

The error arises when the plugin tries to access the target of a connection. In other words, it fails to get the objects at the end of an arrow.

what I will do is searching if I can catch the exception and ask the user between leaving the connection as is (an so the model remains inconsistent but unmodified) or remove the faulty connexion (so the model becomes consistent again but the connexion is lost). As I do not know (yet) how to do this, I unfortunately can't commit to any date even if I do not believe it will take ages :)

But I'm also concerned because this situation should not happen. I mean I do not know why the import process did not complain before. This situation never happened to me. Would it be acceptable for your to send me your database by email as a ZIP file that I can investigate its content:

• Is the information present in the database but badly imported by my plugin
• If not, what is missing and why the import procedure did not complain before

I can sign up a non disclosure agreement if you wish.

Best regards
Hervé

[herve91]

Small update ... I've found an easy way to do it so it will take much less time than I expected :)

Nevertheless, I'm still interested by your model in order to test my update ...

Best regards
Hervé

[jabo59]

Hi Hervé,

thanks for searching for a solution. Unfortunately I cannot send you the database because it contents client material which I'm not allowed to share. Sorry. I will try to reproduce the problem with another model. But this week I'm very busy because my 3 week vacation starts on Saturday. So I'm afraid we must shift further research to end of September.

Best regards,
Jakob

[herve91]

No worries. I'll try do manually change things in my test database to conduct tests.

I'll send a new version soon with the fix soon.

[Phillipus]

@jabo59 Do you use coArchi, the collaboration plugin? If so, has your problem model been used in coArchi?

[jabo59]

@Phillipus: Yes, I‘m using coArchi with this model.

[Phillipus]

@Phillipus: Yes, I‘m using coArchi with this model.

There is an known issue with coArchi that might cause a problem with your model. It might be worth investigating:

archimatetool/archi-modelrepository-plugin#136

[herve91]

Hi Phil,

Thanks for this precision, I didn't know. Nevertheless, I will continue to double check on my side just in case Jakob's issue is not caused by coArchi ;)

Best regards
Hervé

[herve91]

Hi Jakob,

I just released the version 2.2.20 which opens up a popup window which asks if the faulty connexion (or relationship) may be deleted from the model (and thus restore a coherent model but loosing the connexion or relationship) of kept in the model (the model is kept incoherent but can be fixed manually).

Hope this helps
Best regards
Hervé

[jabo59]

Hi Hervé,

thanks a lot. I installed 2.2.20. So far I found no problems. Sorry for my late response.

Best regards,
Jakob