Suppose I have a non-qt object. For example, the QT static-only log handler. How does one cause this file handler to know where to go to look for the current configuration file without, say, hard-coding the application name, organization etc. into the static log-handler function?
I have tried defining a global pointer to the configuration that gets initialized during a startup phase, but this turns out to be a hairy problem to solve during the linking phase. Is there some particular "only-way-is-the-best-way" solution?
(New to QT; if there is an "accepted" or "intended" approach, I would like to take that)
May be create global singleton class?
Or set QSettings::setDefaultFormat() to ini near your binary?
Related
I am consistently experiencing the weirdest thing whenever I use MVVM Light. I create a ViewModelLocator and register in as a static resource in app.xaml:
<viewmodel:WindowsViewModelLocator x:Key="ViewModelLocator" />
Everything works fine, meaning that on launch the static resource is registered, I can use it, and I can see it by going to
App.Current.Resources["ViewModelLocator"]
but then suddenly, randomly, and permanently, this stops working. It has happened to me on every single project, but I'm yet to identify why, as I can't identify the consistent action I did to make it stop working, nor can I figure out any way to revert it back to whatever it was I had when it was working...
the only way to move on is to manually register the resource on startup like this:
if (!Resources.ContainsKey("ViewModelLocator") || Resources["ViewModelLocator"] == null) Resources.Add("ViewModelLocator", new WindowsViewModelLocator());
and finally everything starts working again and usually that's the end of it.
But it happens EVERY SINGLE TIME.
I set a breakpoint in the constructor of the locator and it surely is not being hit... anybody have any idea what I might have possibly done wrong?
EDIT: I finally found the actual exception which was:
A first chance exception of type
'Microsoft.Practices.ServiceLocation.ActivationException' occurred in
GalaSoft.MvvmLight.Extras.DLL
which led me to find the answer which I've posted below. thanks!
It turns out the problem was the order in which I was registering the viewmodels that have dependencies. I have a base ViewModelLocator that initialized the ViewModels, and an inherited ViewModelLocator that contains the Platform-specific code...
In one of the constructors of one of the ViewModels, I was referencing one of the dependent types, which would be registered with a design-time instance. But since this was runtime (which doesn't get registered until it hits the derived platform viewmodellocator) the reference was null.
I moved the dependent code out of the constructor into a more appropriate location and that appears to fix it!
long story short: if you're having this issue, make sure you are initializing everything correctly in the right order and in the right place!
I am new to the usage of reflection in Java/scala. It is not quite clear to me why we need to instantiate a type at runtime. An example would be the best. Thanks a lot.
I will give you a general example of where runtime type instantiation or in general inspection of a types is useful. Think of the Plugin Pattern. Assume you want to create an application that allows users to create plugins. You don't have the plugins the users are going to make in the future, at hand. How are you able to use their plugins after you have released your application? You need to be able to inspect their plugins for a method your application requires and then call said method.
In order to enable this, language designers create a platform in which you are able to query a module (jar in java, assemblies in .net) for the types it defines and the methods, fields, etc it contains. You can then call any method, instantiate any type you want and basically interact with the module as if you had the module at compile time and you were referencing it(well not exactly but you get the point).
Here's and example of a method call that happens at runtime. You can assume that we have already created foo from a string we get from a configuration file at runtime. foo was specified as the name of the jar file containing the plugin types. I don't want to provide the instantiation code as it would make this too bloated, but here is the method:
Method method = foo.getClass().getMethod("doSomething", null);
method.invoke(foo, null);
As you see, we basically got the type of the class foo, we queried it for a method using the method's name and then called it. By doing so we extended the functionality of our program with the plugin at runtime.
Just noticed that there are two name settings in any Typesafe Activator template - one in build.sbt and another in activator.properties.
Is there a way to make one depend on (use the value of) the other? Although the build's name can be defaulted to the name of the main project folder, I'm not sure about the activator's.
You could make build.sbt write out or modify activator.properties, using whatever scala code you want to use for that.
But you'd still have to check activator.properties in to git because the Activator template-publication system does not run sbt on the project, it just looks at the files in git.
And also your nice template intended for end-users would end up with some extraneous build code in it to generate activator.properties, which would clutter up the example.
You could try going the other way but I think it won't work.
In sbt, name is a setting rather than a task, and is thus evaluated only once -- so if you made it read from activator.properties, you'd need to restart (or at least reload) your sbt build whenever you edited activator.properties. But you could read from activator.properties using whatever scala code you like. Something like:
name := {
val props = new java.util.Properties()
props.load(new java.io.FileReader(file("activator.properties")))
props.getProperty("name")
}
However, this is going to fail for two reasons.
When a template is instantiated (cloned) by an end user:
activator.properties is dropped
activator tries to replace the name in build.sbt with a user-selected one
So on clone, first the above code would fail due to missing activator.properties, and second the user's selected name wouldn't be swapped in (because the above expression is too complicated for activator to figure out how to replace it).
This name-replacement means your build.sbt name will get dropped in most cases anyway. The one exception is if the user downloads the "template bundle" (a pre-cloned zip of the project) from the template's detail page on typesafe.com, then the name in your build.sbt would be kept.
Note that if you ever change the name in activator.properties then you'd end up duplicating your template (you'd effectively be publishing a new template), so you may not want to abstract this anyway -- you should change it only when creating a new template is your intent.
Perhaps the bottom line is KISS -- write the name in two places. The alternatives are all going to cause headaches.
The only way I can think of to make this sane would be to have some code outside of the template which generated the template. Akka and Play both do this, I think, for templates that are part of the larger akka and play source trees. But at this point you're definitely doing more work than I'd do just to avoid copying one name string around, you'd want to have some other reason to go there.
I am working on struts 2.0 . I am designing a web application.
I am using Jasper Report in my application. I want to access the *.jrxml files in my action class. I don't want to give hard coded path to the files. So to get the path dynamically I googled it and got the solution that I can get the path using getRealPath() method. But I found two implementation of doing this:
Using HttpSession to get object of ServletContext and using the getRealPath() method of the ServletContext object.
Like this:
HttpSession session = request.getSession();
String realPath = session.getServletContext().getRealPath("/");
The second approach to do it directly using the static method getServletContext() of ServletActionContext. And then we can get the real path of the application using the getRealPath() method.
Like this:
String realPath = ServletActionContext.getServletContext().getRealPath("/");
Please tell me, is there any difference between the above two and also please tell me whether there is any other way to get the path?
Neither is "better", really, and I'd argue that neither is particularly good, either.
I might try getting the context path in an initialization servlet and stick it into the application context, then make your action(s) ApplicationAware and retrieve the value from the map.
This has the added benefit of aiding testability and removing the static references in the action.
That said, I see zero reason to go through the extra mechanics of your first approach: it adds a lot of noise for no perceivable benefit; I'm not even sure why it wuld be considered.
I'd also be a little wary of tying your actions to a path like this unless there's a real need, what's the specific use? In general you shouldn't need to access intra-app resources by their path.
OK my project uses an xml file called Chart-app.xml inside this XML file there is a tag called <version></version> which I keep in the format like: <version>1.2.128</version> I am wondering if I can set it to append to the third number every time I run my project.
So if I ran it now it would be 1.2.129, then if i ran it again it would be 1.2.130
Thanks!!
After reading VonC's answer I don't know anything about ANT or creating custom builds, but he did give me an idea that seems to be working:
I already have a method to tell if the app is running in the ADL (within eclipse), so if it is, I just have my app open the file itself and change the value.
I am not sure there is a native Eclipse way to do this.
You can increment the number within that xml file either:
programmatically, launching a special class which do that, and then call your primary application Class
through a dependency during launch, for instance, you can make a JUnit test suite which will first call a Java class doing the increment, and then call your main method.
But in both case, you would have to somehow code the increment process.
Note: it is easier when you want to increment something each time you build, because you can add a custom builder.