Showing posts from October, 2012

Demonstrating Gemfire Components Configured using spring-data

Gemfire, and the applications that use it are made up of serveral components. There is the data caching tier itself that can exist as one or more data nodes. The data tier can be extended to provide database write-behind, write-through and on-demand read-through. The data tier can also be replicated to remote data clusters through the WAN gateway. WAN replication is not currently part of this example. There is also a client tier that can be pure client, client with local caching and notification client or a combination of the three. Client applications can consume data as they would a no-SQL store, database or they can register for data change notifications with the appropriate callback handlers. Gemfire relies on and makes use of other components including the Gemfire locator and JMXAgent. Gemfire clusters will almost always be be coordinated and linked through the use of Gemfire locator processes. JMXAgents add JMX bean access to a gemfire cluster for management and monit configuration in App.config

I recently (10/2012) converted my TFS build monitor program to be Dependency Injected using the Spring.Net container. I did this because I wanted a no-code way of setting certain parameters and of specifying a build device management class without having to convert a configuration parameter into a class name. I instead injected the spring object with the same name as the configuration parameter using Spring.Net's built in facilities. Spring.Net is moving towards more annotation based configuration but the XML configuration is still widely used and powerful.  You can easily configure Spring.Net in XML with markup inserted into App.config.  The first thing to do is to tell the system that there are going to be some spring.Net sections added to app.config.  This defines two sections, contexts and objects.   context is the section that describes where to find other pieces.   objects  is the section that contains the actual object wiring.  Additional sections might be present if you a

Simple log4net configuration in C# applications

Log4net is the .Net cousin of the very popular Java based log4j logging package.  The simple to use package logs information to a variety of data sinks (appenders) with fine grain control over the amount of output generated by each logging source. log4net is available for download  from the Apache Software Foundation  and is part of the Apache Logging Project  which includes logging libraries for several languages. Log messages are generated by calls through named instances of the  ILog  interface. Each class that wants to log creates an instance of the ILog interface based on the class's fully qualified class name, including namespace.  This means each class has its own entry point into the logging system. In some sense each namespace has it's own common entry point by virtue of the fact that the ILog instances for that namespace all share the same base name/category-name. Callers pass a logging level and message along with an optional Exception objects for certain logging l

Bending NuGet to Your Will by Manipulating the AppData Cache

NuGet decides which versions of dependencies to pull in based a combination of the way dependencies are specified in the dependent packages and the packages that are available on your feeds.  NuGet drills down pulling all of a components direct dependencies and its indirect dependencies based on the nspec specifications of each pulled in component. This lets you pull in some  OSS component and then its dependencies down to bottom level which might be something like a Microsoft component. NuGet compares the versions specifications when resolving those to NuGet packages on a feed. Here are some example version specifications for the Microsoft MVC "4.0.20505.0"  MVC 4.0 RC or later "[4.0.20505.0]" MVC 4.0 RC only "[4.0.20505.0, 4.1] MVC 4.0 RC through any version of 4.1 "[4.0.20505.0, 4.0.20710.0) MVC 4.0 RC and all up to but not including MVC 4 RTM You can run into problem when new versions of dependencies appear on feeds and dependencies are inccor

Why is the Installer is My Least Favorite Piece of the Microsoft Platform.

I worked on a project where we were contractually restricted to Microsoft products after years of using Java and Open Source tools.  Microsoft tooling is kind of interesting because you get a integrated environment where the MS teams have taken on the burden of implementation. It's not a confused jungle of choices where some big pieces integration are left to you.  The MS world moves at a pace driven by Microsoft itself, often faster than JCP driven Java.  OSS and Java either barely move or go really fast but in a whole bunch of different directions all at once.  Which is pretty, is  much a matter of personal taste. Microsoft and its tooling is installed and managed through GUI installers that bind the installed software/tool to the target machine. Its not like a directory is created and some stuff is registered.  Files are copied different places and system libraries can be updated or overwritten.  This installer and its implications has turned out to be the most annoying thing