Setting Up the .NET Program
Double-click on the Project\DotNet\LogDemo.sln
file to open the .NET project. Before building the project, add the proxies to the project by adding a reference to the assembly loggingProxies.dll
that you created in the preceding section. You also need a reference to the assembly jnbshare.dll
that you'll find in the JNBridgePro installation folder. Jnbshare.dll
contains the core JNBridgePro functionality used to manage communications with the Java classes. After adding the references, you should be able to build the project without errors.
|Figure 3. Starting the Binary Server: Here's an example of the command line to start the Java side. Note that your paths may differ from the ones shown here.|
To finish setting up the .NET program, copy the file jnbproxy.config
into your build folder, which will either be bin\release
, depending on your Visual Studio project build settings. jnbproxy.config
contains configuration information that tells the .NET side where the Java code is located and which protocol will be used to communicate with it. In this case, jnbproxy.config
specifies that the Java code is located on the same machine as the .NET code, that it will listen on port 8085, and will communicate with the binary protocol.
Running the Program
If you examine Form1.cs, you'll see that it uses the BasicConfigurator class, which for demonstration purposes causes logged messages to appear in the Java console window. Note that it's quite possible to log to files, JMS publishers, or other endpoints.
Before starting the .NET program, you'll need to start the JVM containing the Java classes, so they'll be able to receive the requests from the .NET side. Do this by opening a command-line window and typing in the following command line:
java --cp <path to Project\Java>;<path to jnbcore.jar
in JNBridgePro installation folder>;<path to log4j-
1.2.8.jar> com.jnbridge.jnbcore.JNBMain /props
<path to jnbcore_tcp.properties in JNBridgePro
To be safe, surround each of the paths in the preceding command line with quotes, because they may contain spaces. The jnbcore.jar
file contains the core JNBridgePro functionality that allows Java classes to communicate with the .NET side. The jnbcore_tcp.properties
file contains configuration information that tells Java which communications protocol to use and which port to listen on for requests. The sample project uses the binary protocol and listens on port 8085. Figure 3
shows what you will see if all goes well.
|Figure 4. The Logging Application: The figure shows the .NET front-end application that lets you log messages from either .NET or Java.|
Next, start the .NET program from Visual Studio .NET, or simply by double-clicking on LogDemo.exe
. Figure 4
shows the running application.
Clicking on the "Log .NET event" button causes the DotNetClass to log an event from .NET. Click on the "Log Java event" button to cause JavaClass to log an event from Java. You can either supply a custom message to log or just use the supplied defaults. In each case, the Java-based log4j package performs the logging operation, and displays the logged messages in the console window, as shown in Figure 5
In this project you've seen how to log messages from both .NET and Java code into a common logging packagein this case running on the Java platform. Using a common logging package consolidates .NET-originated and Java-originated logging messages in the same console window or file, and lets you easily see the sequence of from both the .NET and Java sides.
|Figure 5. Logged Messages in the Console: Here's how the logged messages appear in the console window.|
More generally, you've seen how call to Java classes directly from .NET by using a runtime bridge. In the sample application, .NET code calls Java classes in the log4j package, and also calls the Java class JavaClass. You can easily extend this technique of directly accessing Java classes from .NET to other Java class libraries, and you can also use it to let .NET classes access EJBs, JMS queues, or other Java and J2EE capabilities. Using a runtime bridge is simple, transparent, and extensible, because your .NET code accesses the Java code through proxies, and has no idea that it's talking to Java classes.