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.
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.
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?
I'm trying to use the new org.omnifaces.converter.ListConverter in a primefaces picklist.
I added the new dependency in my project with maven and rebuilt the project in order to download the jar file:
<dependency>
<groupId>org.omnifaces</groupId>
<artifactId>omnifaces</artifactId>
<version>1.5</version>
</dependency>
I'm importing the namespace in my facelets as follows:
xmlns:o="http://omnifaces.org/ui"
Still, when I try to use <o:converter> in my picklist as follows:
<o:converter converterId="omnifaces.ListConverter" list="#{projectBean.clientSource}" />
I get a message from netbeans 7.3 saying :
The attribute list is not defined in the component converter
It doesn't seem to cause any build failure though...
Am I missing something? Do I not use omnifaces as it is meant to be?
This is, unfortunately, "by design".
Netbeans apparently validates the attributes rather strictly based on their registration in the *.taglib.xml file.
The <o:converter> is supposed to support all attribtues of any arbitrary converter, such as pattern and locale of <f:convertDateTime>, the minFractionDigits and integerOnly of <f:convertNumber>, etcetera. It's however impossible to register all of those attributes in the *.taglib.xml file in order to satisfy all possible use cases of <o:converter>. It namely also supports custom converters instead of standard ones.
It's however valid to specify a "custom" tag attribute and this is where the <o:converter> relies on. The list attribute is actually an attribute of the omnifaces.ListConverter converter. I don't have Netbeans at hands and I'm not sure whether it interpretes it as an error or as an warning and or if it's configurable somewhere in its validation settings, but I can assure you that this is absolutely harmless and should at most generate a warning (and thus not as an error).
In case you didn't understood the use of <o:converter>, it's a special tag handler which evaluates the attributes of the specified converter during view render time instead of view build time. This way it's possible to supply "dynamic" attributes tied to bean properties instead of hardcoded string attributes.
I worked around this issue in netbeans by unzipping omnifaces-2.1.jar.
Edit omnifaces-2.1\META-INF\omnifaces-ui-taglib.xml
Find converter
Add an attribute under converter:
<attribute>
<description>
<![CDATA[
Model source list http://showcase.omnifaces.org/converters/ListConverter
]]>
</description>
<name>list</name>
<required>false</required>
<type>java.lang.String</type>
</attribute>
Just before < /tag >.
Zip the extracted contents (META-INF and org folders) into onmifaces-2.1.jar.
Use that jar in netbeans.
The first time when you add the dependency, netbeans don't update its namespaces list.
Then,
Execute "Clean and Build"
In some cases, restart Netbeans
And its all
The same has happened to me with omnifaces 1.7 and Netbeans 7.3.1
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.