We've encountered a problem with RPC and want to increase the logging level of Kryo to be able to investigate. The Kryo docs suggest running Log.TRACE(), but we can't find anywhere to do this within Corda.
Is there any way in Corda, or in our CorDapp to do this?
If you're using Log4j to configure logging, as we do in the template CorDapps (e.g. https://github.com/corda/cordapp-template-kotlin/blob/release-V2/config/dev/log4j2.xml), you just need to change the logging level in the log4j2.xml file.
Change:
<Configuration status="info">
To:
<Configuration status="trace">
Related
How to get config file for Cordapp in Java like in sample?
serviceHub.getAppContext().config
After getAppContext() i can't find anything about config file.
This feature is not available in Corda 3. As of this answer, it is only part of the unstable master branch. It will be included in a future release of Corda.
However, you can implement this manually for now as follows: How to provide a CorDapp with custom config in Corda?.
I have activemq-client-5.13.3.jar on my class path, but i keep getting
Exception in thread "main" java.lang.NoClassDefFoundError: javax/jms/JMSException
If i use activemq-all-5.13.3.jar on my class path, every thing works.
however I am not allowed to use the activemq-all jar.
added jms-api-1.1-rev-1.jar
and now Exception in thread "main" java.lang.NoClassDefFoundError: javax/management/j2ee/statistics/Stats
You can use maven to determine this with the mvn dependency:tree command or use other maven centric tools to explore the artifacts dependencies.
At a minimum you would need these for v5.13.3
slf4j-api.jar geronimo-jms_1.1_spec.jar hawtbuf.jar
Then you can add an slf4j binding like log4j or logback to get proper logs. There are some others that you might want depending on where / how you are using it like the geronimo-j2ee-management_1.1_spec jar.
Of course if you use maven to build you can make this simpler since it will manage the deps for you.
I found same problem with my java application. I needed to insert Spring Boot for rest web service (Jetty Server) and now ActiveMQ for others data exchange.
With
activemq-client-5.15.11.jar; geronimo-jms_1.1_spec-1.1.1.jar; geronimo-j2ee-management_1.1_spec-1.0.1.jar; hawtbuf-1.11.jar;
all works.
When closely observing Web.config, all the possible child elements of <configuration> are also present inside configuration/runtime.
I have never encountered a need to specify values in configuration/runtime section. Have you come across this situation?
What is the purpose of specifying values in runtime section ?
The purpose of <configuration><Runtime> settings as described in msdn here
is
"Runtime settings specify how the common language runtime handles
garbage collection and the version of an assembly to use in
configuration files."
These are CLR settings that you can configure for your application. The possible settings directly under <configuration> is the not the same as <configuration><Runtime>. You can refer to the <configuration> schema here
To add to above reply i did face real time situation to use
"runtime" element for configuring Assembly binding.
I was using Ninject which was referring to System.Web.MVC 3.0.0.0 while i was having System.Web.MVC with version 5.0.0.0
This was causing IOFileNotFound exception
By Adding "runtime" binding i could redirect any binding for System.Web.MVC to 5.0.0.0 verison.
So as you may or may not know, BlazeDS (open source version of LiveCycle Data Services) is a nice way to get your server-side Java and client-side Flex application to play together. Unfortunately, it does have several pitfalls that need to be corrected. I'll try to explain one of them here.
All of BlazeDS's configuration is written via XML files in the flex/ folder of your webapp. The default names are separated for clarity, such as services-config.xml, remoting-config.xml, messaging-config.xml, etc. In these configuration files (particularly services-config.xml), Channels are defined; these setup URIs and objects used to capture and send information between the server and the client. In these config files, it is quite common to use a syntax like so:
<channel-definition id="my-secure-amf" class="mx.messaging.channels.SecureAMFChannel">
<endpoint url="https://{server.name}:{server.port}/{context.root}/messagebroker/amfsecure" class="flex.messaging.endpoints.SecureAMFEndpoint"/>
<properties>
<add-no-cache-headers>false</add-no-cache-headers>
</properties>
</channel-definition>
Unfortunately, what they don't tell you is that some of these key-in replacements (ie: {context.root}) are not replaced dynamically upon execution but upon compilation of the WAR file you intend to distribute. Obviously not a good idea when switching domains.
So, instead I seek to dynamically define these channels. According to the documentation, that's all good and fine, but it only works if the channel already exists when the webapp is launched. I feel like that sort of defeats the point.
So my question is, how do you truly create channels dynamically so that both the client and the server recognize their existence?
Read this blog post; I believe it is what you're after.
I believe these xml config files have no direct relation to the server at all. They are used to tell the SWF how to find the server.
During Compile time of your Flex App; the services-config information is, in essence, hard coded into the SWF.
I'm developing a web application (ASP.NET 3.5) that will consume a number of web services. I have created a separate dll-project for each web service: these projects contains the service reference and client code.
However, the calling website MUST have the <system.serviceModel> information (the <bindings> and <client> nodes) in it's web.config, even though this information is also in the dll's app.config file! I have tried copying the serviceclass.dll.config over to the bin directory of the website, but this didn't help.
Is there any way to centralize the configuration of a WCF client?
I've only limited WCF experience, all with BasicHTTP bindings. But I'm allergic to WCF's xml files and have managed to avoid them thus far. I don't recomend this generally but I put the configuration details in my apps existing configuration store and then apply them programatically. E.g. With a Web service proxy I use the constructor for the Client that takes 'bindings'and 'endpoint' and programatically apply the settings to the bindings & endpoint.
A more elegent solution appears to be descibed here: Reading WCF Configuration from a Custom Location, but I haven't tried it yet.
From my experience, library projects never read app.config.
So you can really delete the file because it is not used. The library's host configuration is read instead, so that is the only place the endpoint and binding configuration should be.
It's possible to forgo xml config and build up the Binding and Endpoint classes associated with the service in the constructor or a custom "Service Factory". iDesign has some good information on this:
http://www.idesign.net/idesign/DesktopDefault.aspx?tabindex=5&tabid=11
(See In Proc Factory)
In their approach, you set attributes on your services to specify at a high level how they should work (ie [Internet], [Intranet], [BusinessToBusiness]), and the service factory configures the service according to best practices for each scenario. Their book describes building this sort of service:
http://www.amazon.com/Programming-WCF-Services-Juval-Lowy/dp/0596526997
If you just want to share configuration XML config, maybe use the configSource attribute to specify a path for configuration: http://weblogs.asp.net/cibrax/archive/2007/07/24/configsource-attribute-on-system-servicemodel-section.aspx
Remember that a configuration file is is read by an executable that has an entry point. A library dll does not have an entry point so it is not the assembly that will read it. The executing assembly must have a configuration file to read.
If you would like to centralize your web configs then I would suggest you look into nesting them in IIS with virtual directories. This will allow you to use the configuration inheritance to centralize whatever you need.
There are 2 options.
Option 1. Working with channels.
If you are working with channels directly, .NET 4.0 and .NET 4.5 has the ConfigurationChannelFactory. The example on MSDN looks like this:
ExeConfigurationFileMap fileMap = new ExeConfigurationFileMap();
fileMap.ExeConfigFilename = "Test.config";
Configuration newConfiguration = ConfigurationManager.OpenMappedExeConfiguration(
fileMap,
ConfigurationUserLevel.None);
ConfigurationChannelFactory<ICalculatorChannel> factory1 =
new ConfigurationChannelFactory<ICalculatorChannel>(
"endpoint1",
newConfiguration,
new EndpointAddress("http://localhost:8000/servicemodelsamples/service"));
ICalculatorChannel client1 = factory1.CreateChannel();
As pointed out by Langdon, you can use the endpoint address from the configuration file by simply passing in null, like this:
var factory1 = new ConfigurationChannelFactory<ICalculatorChannel>(
"endpoint1",
newConfiguration,
null);
ICalculatorChannel client1 = factory1.CreateChannel();
This is discussed in the MSDN documentation.
Option 2. Working with proxies.
If you're working with code-generated proxies, you can read the config file and load a ServiceModelSectionGroup. There is a bit more work involved than simply using the ConfigurationChannelFactory but at least you can continue using the generated proxy (that under the hood uses a ChannelFactory and manages the IChannelFactory for you.
Pablo Cibraro shows a nice example of this here: Getting WCF Bindings and Behaviors from any config source
First of all class libraries (DLLs) do not have their own configuration, however they can read the configuration of their host (Web/Executable etc.). That being said, I still maintain an app.config file on the library projects as a template and easy reference.
As far as the service configuration itself is concerned, WCF configuration can make somebody easily pull their hair out. It is an over-engineered over-complicated piece. The goal of your applications should be to depend least on the configuration, while maintaining flexibility of deployment scenarios your product is going to come across.