Closed SeanCarrick closed 2 years ago
Okay, after some scrambling to figure out how to get a remote branch, I got it in and did "Clean and build" that was successful, and then clicked "Run" and I got the application main screen, I am assuming. (See attached pic.)
The "About" box looks good, but I get some exceptions when I click on "Tools -> Options." I will attach a file of the Output window in Netbeans named "refactoring-away-from-cyclic-dependencies.txt".
With no new information and the inability to recreate the exceptions on my end, I am going to go ahead and merge this request to start working on the next item on my TODO list: the NTA.Bug.Reporter module. This next task will assist in tracking down what could possibly be causing the exceptions that @knathan54 is receiving when he tries to run the project...
-SC
Note: I am starting with this note because of the number of files affected by this PR. No mind needs to be paid the individual files in this PR. The important part of the approval or rejection is, "Does it work?". This note is mostly here for @jkovalsky, because I know how he immensely despises PRs with tons of files in them. However, I promise that this will be the last one. End of Note
I have created three new modules: GS.United.Labs.API, NTA.Logging, and NTA.Properties; in an effort to shrink the size of the NTA.Foundation module. The Foundation module had been growing because I kept trying to create other modules and would end up with cyclic dependencies, so I would take the contents of the various modules and add their packages into NTA.Foundation to get rid of the cyclic dependencies. However, with NTA.Foundation growing as big as it was, I would have ended up with everything in it, which would have completely defeated the purpose of the move to the modular architecture.
So, to be able to move such things as the
Logger
andProperties
back to their own modules, I created three new interfaces in the GS.United.Labs.API module:GSLogRecord
,GSLogger
, andGSProperties
. I then refactored theLogRecord
,Logger
, andProperties
to implement these new interfaces, respectively. With this change in place, we no longer directly instantiate theLogRecord
orLogger
classes. Instead, we use theServiceLoader
mechanism to get an instance of these two objects. Due to making this modification, thegetInstance()
had to go away because theServiceLoader
calls a default no-args constructor and does not provide a way of calling agetInstance
method.A problem with this change arose due to how I had the
Logger
naming itself. Both of thegetInstance
methods took theApplication
object. One of those methods took aString
of the class name, and the other took the class itself. Either way, the constructor built the log file name as:Now, when the logFileName is built, its name ends up being "NTA-Basic - null.log" for every class that uses a
Logger
. This kind of defeats the purpose of the naming convention. To fix this issue, the new way to load the instance variable is:Now, the
Logger
is initialized with the first (and, in NTA, only)Logger
class that theServiceLoader
finds. And, there is no longer a cyclic dependency between NTA.Foundation and NTA.Logging. Furthermore, all of the logging functionality has been split off into its own module, which is made up of a whopping three classes. That is a proper module!Then, taking it a step further, I did the same with the
Properties
class...made an interface thatProperties
now implements, and moved it to its own module, NTA.Properties. The only difference is that theProperties
class can be directly initialized because, though it relies on theApplication
class of the AppFramework, it does not rely upon theNTApp
class. This means that the NTA.Foundation module canrequire NTA.Properties
without worry, unlike with theLogger
class.And, going even a step further, I refactored the
com.gs.nta.api
package out of the NTA.Foundation module into the GS.United.Labs.API module. NTA.Foundation is definitely having some much-needed weight loss. Do not get me wrong, it is still rather large...After I had all of this completed, I refactored the
com.gs.nta.utils
package into its own module, NTA.Utils. I have also created a module called NTA.Bug.Reporter that I have barely started working on.Even with all of this work done, I have gotten the
com.gs.nta.desktop.panles.ProxyOptionsPanel
almost fully functional for loading, editing, and saving proxy settings, default web browser, and anonymous usage statistics checkbox settings to the application properties and other config files. I said "almost fully functional" because I am having an issue getting the fields on the Web Browser Manager to act right when the web browser selection in the list changes. However, I do have adding and removing those browsers working fine.So, that just about covers everything that is in this PR. Now you can see why there are so many affected files. After this one, large, PR, I promise, @jkovalsky, I will do my best to keep them reasonable. Please forgive me this once. :grin:
-SC