We are upgrading to solr 4.4 and would like to be able to use the new core.properties for the new core discovery.
Currently, we have a couple of properties defined in the solr.xml for most of the cores, and I am not able to create these same properties in the new core.properties file.
Here is a core as currently defined in solr.xml:
<core name="core1003" instanceDir="core1003">
<property name="xmlDataDir" value="D:\Solrfiles\ImportFiles\core1003.xml" />
</core>
This is then used in DIH-XPathEntityProcessor.xml with <str name="xmlDataDir">${xmlDataDir}</str>.
How can I define core specific property variables like this? It doesn't necessarily have to be in core.properties, but that would make it a little easier to manage.
In your core instance directories that contain your core.properties file create a conf/ subdirectory and a solrcore.properties file in it. Define your core specific properties there and it will be picked up automatically.
Alternatively, you can add a value for "properties" to your core.properties file to point to any other file:
properties=/your/path/here.properties
I believe but have not confirmed that for this to work your cores must load on startup and must not be transient. Any non-standard properties you add to core.properties will be ignored because the CoreDescriptor copy constructor only persists the following properties from that file in memory: instanceDir, config, schema, name and dataDir (see CoreDescriptor:91 in the 4.4.0 source). I believe this is a bug?
Related
When in a .sln file, you have the default choices of 'Debug' and 'Release'. From what I understand these are 'build settings' of some sort differ depending on the kind of build you are doing?
I recently played around with creating my own settings, and found (much to my surprise) that creating the configuration name didn't seem to create the symbol as recognized by:
#if MY_SHINY_NEW_SYMBOL
Console.WriteLine("TESTING MY SYMBOL");
#endif
And on the Microsoft docs I can see that there is code to allow you to actually define the symbol (presumably separately from just creating one in the Configuration Manager):
#define DEBUG
// ...
How do these symbols work and where are they configured?
i'm asking because I accidentally created a symbol called 'local'. I deleted it and then created a symbol called 'Local'. And I'm getting compile errors because it seems that the 'local' symbol still exists and I can't overwrite it with a symbol using a different case.
I haven't configured the symbol at all, I'm using the variable $(ConfigurationName) in my pre-build event commands.
I'm actually fairly sure this is a Visual Studio bug, since I would think that deleting a configuration, recreated the same configuration with different case, would NOT result in the original configuration reappearing.
Build configurations become MSBuild variables that can be referenced in MSBuild properties in the csproj file (remember that .Net project files are actually MSBuild scripts).
In particular, the Visual Studio Project Properties window will let you set most properties on a per-configuration basis (by wrapping it in a conditional block).
In particular, the DEBUG symbol is set like this (you'll see this in every csproj file, but a bit less simple):
<PropertyGroup Condition=" '$(Configuration)' == 'Debug' ">
...
<DefineConstants>DEBUG;TRACE</DefineConstants>
...
</PropertyGroup>
You could also replace this and set a symbol for the configuration directly:
<DefineConstants>$(Configuration)</DefineConstants>
However, VS is likely to change that if it saves your project file.
I renamed a folder and updated my namespace declarations, but ReSharper 6 claims that the namespace should be a reflection of how it was before the rename. Where is it storing the file location data?
Check to make sure your assembly name matches your new namespace. If you've changed your folder structure to match your new namespace, you may still see the ReSharper alert until you update the project properties.
As delliottg's comment says, in Visual Studio, go to
Project > [project name] Properties > Application
and change "Assembly name" as well as "Default namespace".
I also had this problem with a folder/namespace and none of the above steps fixed it.
In my case I had to do this in Visual Studio:
Right-click the "problem" folder in the solution explorer to open the properties
Ensure the "Namespace Provider" is set to true
This fixed the ReSharper issue for me and I was able to adjust namespaces as normal.
Root namespace is needed to be changed as following.
I use Resharper 2019.3.2 in VS 2019 vs 16.5.2 and I had similar issues.
When developing, I first work out my namespace hierarchy in a single project, then split the project in seperate class libraries. In the first stage, it is convenient to always let the subdirectory correspond to the namespace.
For example, my prototype MeshTools.dll project currently contains:
Meshtools ........................ 3 cs-files in \MeshTools
MeshTools.HeightField .......... 2 cs-files in \MeshTools\HeightField
MeshTools.VectorTools .......... 3 cs-files in \MeshTools\VectorTools
The above answers all assume one single namespace per project. Renaming directories manually may confuse Resharper and that can be repaired by setting the default assembly in the .csproj file to the proper namespace. Thanks for the tip.
However in my case, I have several namespaces in a single project, with each namespace in a Solution directory corresponding to a real directory. Setting the default assembly "Meshtools" does not affect ReSharper behaviour for HeightField and VectorTools, when things have gone wrong with the renaming.
I googled this issue and came by https://www.jetbrains.com/help/resharper/Refactorings__Adjust_Namespaces.html#
It turns out there is a right-click option on a Solution Directory -> Properties. You will find an option to decide, if the Solution Directory is a NameSpace provider or not. When something has gone wrong, Visual studio will reset the field to False. Set it back to True and Resharper will correctly refactor namespace or file location when needed..
If you're using JetBrains Rider, go to the Solution Explorer and right click on the csproj file, then properties in the context menu. In my case the Assembly Name was already updated but "Root Namespace" wasn't, updating Root Namespace allowed JetBrains to automatically update all namespaces.
Packaging a log4j configuration file in a NetBeans Platform application apparently requires some thinking through. This is what I tried...
I put log4j.xml in src/main/resources/my/package/log4j.xml of some_netbeans_module. The package is a public module package (i.e. classes from this package are used from other packages). I rebuilt the module and confirmed that the file does, in fact, get packaged into the module.
In my classes I get an instance of the logger the way I always do:
static final Logger log = Logger.getLogger(ThisClass.class);
Every NetBeans Platform application has a my_app.conf file which makes it possible to set certain properties. This is where I set log4j.conf:
log4j.configuration="/my/package/log4j.xml"
Now, when I run the application, I see the following output:
[INFO] /home/me/my_app/application/target/my_app/bin/../etc/my_app.conf: 5:
log4j.configuration=/my/package/log4j.xml: not found
What is wrong with the above configuration?
In the my_app.conf file if you append the log4j.configuration property to the default_options property, like so:
default_options="...<other options> -J-Dlog4j.configuration=my/package/log4j.xml"
then this option will get passed to the JVM. Notice that the log4j property has -J-D appended to it. The -J is used by NetBeans to delineate JVM properties and the -D is used by the JVM to delineate a system property.
Also you can/should drop the quotes and the initial / as the quotes are not necessary and NetBeans will complain if you have the initial /
The other way to do this, and the way that I prefer since it doesn't require editing the .conf file, is to put the log4j.xml file into the default package. If you have other requirements that prevents you from doing this then remember that you must put the log4j.configuration property in the app's platform.properties file while your in dev mode and running the app inside of the IDE. Like so:
run.args.extra=-J-Dlog4j.configuration=my/package/log4j.xml
Edit: For questions regarding NetBeans Platform you might have better luck posting to the NetBeans Platform Users forum.
I'm using the Maven Appassembler plugin to package my application. I'd like to package some configuration files with the application. I've found the configurationDirectory and includeConfigurationDirectoryInClasspath parameters, but I haven't found how I should create (and populate) that configuration directory. I've tried putting the files in src/main/resources, but that just puts them in the jar file for my project.
What is the "proper" way to do this, using maven?
Unfortunately this is a limitation of the appassembler plugin in the current release version. Typically, the plugin is used in conjunction with the assembly plugin to produce the final artifact, in which you can include the reference to your configuration directory. However, if you'd like to have a functional structure from just the appassembler plugin you need to manually copy the files into place. An example using the antrun plugin with a src/main/conf directory can be found here: http://svn.apache.org/viewvc/archiva/trunk/archiva-jetty/
By default, the plugin uses the directory src/main/config.
Is possible to change the source for the config files using the parameter <configurationSourceDirectory>src/main/config</configurationSourceDirectory>
When I include the copyConfigurationDirectory property, it copies the config files and bundles them properly.
<configurationDirectory>etc</configurationDirectory>
<configurationSourceDirectory>src/main/config</configurationSourceDirectory>
<copyConfigurationDirectory>true</copyConfigurationDirectory>
I have a different problem though. I would like to filter my config files before copying, which is giving me some trouble.
Apart from that is does not generate the bin scripts for different platforms. The maven-assembly-plugin can create (package(s) {tar.gz, zip}) for distribution. These are configured through a assemble.xml. You specify which files go in (with what options (chmod)), etc. It can also filter files (search/replace values within them). etc.
Years later and in version 1.10 of the plugin there is now a preAssembleDirectory configuration option. Unfortunately I don't find it flexible enough for my needs because it copies directly into assembleDirectory and does not allow to specify a target directory path within assembleDirectory.
I've created a custom binding and want to make it configurable over App.config.
The binding has no special options at the moment, so it would be sufficient to support just
<endpoint address="http://myAddress"
binding="myBinding"
contract="myContract">
After checking some sites, I found out that I have to enable configuration support through a <BindingExtension>. However, the MSDN site didn't help much, since when I try to add
<extensions>
<bindingExtensions>
<add name="myBinding"
type="MyNamespace.MyHttpBinding, NameOfMyDll, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null"/>
</bindingExtensions>
</extensions>
, I only receive the following error message when trying to launch the program:
Configuration binding extension 'system.serviceModel/bindings/myBinding' could not be found. Verify that this binding extension is properly registered in system.serviceModel/extensions/bindingExtensions and that it is spelled correctly.
The type mentioned in the bindingExtension points to the type which inherits from Binding.
What do I have to add to enable configuration support for my binding?
My goal is just to be able to export my binding to the config file. I don't want to allow any special settings for the binding. It should just be usable over the config file's <endpoint> tag.
You're on the right track. The key point, however, is that the bindingExtension element should not point directly to your binding class itself.
Instead, you need to have several class that support the configuration model.
For starting, the bindingExtension you register is really a class that inherits from StandardBindingCollectionElement. This represents a collection of StandardBindingElement, which is the configuration class that has all the configuration properties that your binding will support in the .config file and would be responsible for creating your Binding instance and setting any properties on it that were set in the .config file.
Also, notice that, normally, you'd follow a similar pattern for creating a configuration view of your TransportBindingElement (if you're doing a transport channel) so that you can create custom bindings using it though configuration. In that case, you'd have a class inheriting TransportElement.
P.S. If you're thinking this is an awful lot of repetitive code if you've got lots of settings, then I agree.
Update: Found what your problem was: You need at least an empty <bindings/> section in your config file. Just add it and the binding will be recognized now.