Tag Archives: Lamar

Lamar v0.9 — Decorators and “MVP”

Lamar, which started life as “BlueMilk,” is the now permanent codename for my next generation IoC tool that is meant to replace StructureMap in new .Net Core projects. I did a little bit of work this morning to add in at least the basic functionality for decorators similar to what StructureMap has supported since 3.0 (but no other kinds of interception for now):

[Fact]
public void decorator_example()
{
    var container = new Container(_ =>
    {
        // This usage adds the WidgetHolder as a decorator
        // on all IWidget registrations
        _.For<IWidget>().DecorateAllWith<WidgetHolder>();
        
        // The AWidget type will be decorated w/ 
        // WidgetHolder when you resolve it from the container
        _.For<IWidget>().Use<AWidget>();
        
        _.For<IThing>().Use<Thing>();
    });

    // Just proving that it actually works;)
    container.GetInstance<IWidget>()
        .ShouldBeOfType<WidgetHolder>()
        .Inner.ShouldBeOfType<AWidget>();
}

This change, and a few other miscellaneous fixes for integration with Jasper, are available on Nuget in Lamar 0.9.0. At this point, I feel like Lamar is already at the feature set I intend to support for a 1.0 release. It’s going to at least go through some load testing at my work over the next month, and still lacks documentation (but most of it behaves identically to StructureMap or the ASP.Net Core DI compliance). All the same,  I’m declaring it ready for real usage if anybody is up for trying it out and hopefully sharing any feedback. It should *mostly* be a drop in replacement for StructureMap if you’re not doing too much weird stuff.

For more information, see some of my previous blog posts about Lamar/BlueMilk:

 

Advertisements

Integrating Jasper into ASP.Net Core

Continuing a blog series on Jasper functionality:

  1. Jasper’s Configuration Story 
  2. Jasper’s Extension Model
  3. Integrating Marten into Jasper Applications
  4. Durable Messaging in Jasper 
  5. Integrating Jasper into ASP.Net Core (this one)
  6. Jasper’s HTTP Transport
  7. Jasper’s “Outbox” Support within ASP.Net Core Applications

There will be some need for completely headless services written with Jasper that rely strictly on TCP connections or yet to come queueing transports, but I expect that most of the systems at work where we’ll use Jasper will be within ASP.Net Core applications.

Moreover, as a nasty lesson learned from my hubristic attempts at creating a freestanding development ecosystem with FubuMVC, Jasper is meant to be merely a good citizen within the greater server side ASP.Net Core ecosystem. In regards to this blog post, that means using as much of the standard Hosting model as possible. For example, Jasper supports the IHostedService model from ASP.Net Core out of the box for long running background services or startup and shutdown actions.

As of Jasper 0.6, I pulled the HTTP support and ASP.Net Core integration into a separate Jasper.Http Nuget. This might feel like the tail wagging the dog, but I really only did this to optimize the core Jasper testing suite because bootstrapping ASP.Net Core on every integration test was slowing the automated build down too much. If I can find a way to optimize or at least parallelize much more of the bootstrapping with the messaging, I will consider merging things back together again later.

When Jasper is integrated into an ASP.Net Core system, it:

  • Adds more service registrations to the application
  • Bootstraps the JasperRuntime object and places that within the container so that the Jasper transports will be cleanly shut down when the IWebHost is disposed
  • Replaces the built in DI container with Lamar (Jasper only works with Lamar at this point)
  • Jasper also sneaks in some ASP.Net Core middleware to add its own routes into the application, which I’ll show off in the next post about Jasper’s HTTP messaging transport

All of this is documented in the Jasper Getting Started page and in the specific documentation for ASP.Net Core integration.

Longer term, I might try to move Jasper closer to the existing ASP.Net Core bootstrapping mechanisms.

Bootstrapping ASP.Net Core the Idiomatic Jasper Way

The first option is really about adding HTTP support to an idiomatic Jasper application. In this case, you just use the JasperHttpRegistry from the Jasper.Http library as the base class for your application definition like so:

public class AppWithMiddleware : JasperHttpRegistry
{
    public AppWithMiddleware()
    {
        // Do the normal stuff you do to configure
        // service registrations, configuration, and
        // messaging support

        Http.Configure(app =>
        {
            app.UseMiddleware<CustomMiddleware>();

            // Explicitly control the order in which the Jasper
            // middleware is placed within the ASP.Net Core
            // pipeline. 
            app.AddJasper();

            // Just to show how you can configure ASP.Net Core
            // middleware that runs after Jasper's RequestDelegate,
            // but do note that Jasper has its own default "not found"
            // behavior
            app.Run(c =>
            {
                c.Response.StatusCode = 404;

                return c.Response.WriteAsync("Not found");
            });
        });
    }
}

A couple things to note:

  • The Http property in the class shown above is just the IWebHostBuilder interface you’re already used to if you use ASP.Net Core today
  • If the call to IApplicationBuilder.AddJasper() is omitted, Jasper will add its own middleware to the very end of the pipeline
  • The HTTP bootstrapping in the idiomatic model is somewhat parallelized with the messaging support bootstrapping
  • I’d argue that this usage makes the ASP.Net Core StartUp conventional configuration model unnecessary, but you’re perfectly able to continue using that if you want.

I hope to do more optimizations to the cold startup time in the future for the idiomatic Jasper approach that would make this option be more attractive. Right now, the biggest reason to use this approach over the following is to be able to use Jasper’s console application harness and Storyteller integration.

 

Adding Jasper to an Existing ASP.Net Core System

You can also add Jasper to an existing ASP.Net Core system using its idiomatic bootstrapping approach. In this case, you still start with the JasperHttpRegistry base class from the Jasper.Http library, but you mostly use this to configure the messaging support:

public class SimpleJasperBusApp : JasperHttpRegistry
{
    public SimpleJasperBusApp()
    {
        // Enable the HTTP messaging transport
        Http.Transport.EnableListening(true);
        
        // Listen for TCP messages at port 2222
        Transports.LightweightListenerAt(2222);
    }
}

Then, to add the Jasper support to your ASP.Net Core application, you would add these calls:

var builder = new WebHostBuilder();
builder
    .UseKestrel()
    .UseUrls("http://localhost:3003")
    .UseStartup<Startup>()
    
    // This *has* to be the last call 
    // to your IWebHostBuilder
    .UseJasper<SimpleJasperBusApp>();


theHost = builder.Build();

theHost.Start();

I hate this from a usability perspective, but for right now, the call to UseJasper() has to be added after any other IStartUp registration including the UseStartup<T>() method. You still have the same ability to explicitly control the order of the Jasper middleware within your ASP.Net Core middleware pipeline.

 

 

 

Jasper v0.6: Better outbox usage, Lamar, ASP.Net Core integration changes

I’ve been a little distracted with the Lamar/BlueMilk work and Marten bug-fixing, but Jasper is still rolling along and about to get into production at work (a super early prototype is running in a low volume system now). I just pushed Jasper 0.6 to Nuget with some new improvements. The documentation has been updated and reflects the new changes described below.

Big changes:

  • Jasper uses Lamar for all IoC usage. I’m still very confident that the Jasper + Lamar (was “BlueMilk”) combination will lead to a very effective combination of flexibility and performance in the runtime pipeline. Lamar natively supports all the ASP.Net Core DI abstractions, so if you don’t care about any of its advanced features you don’t even need to care that it exists.
  • I broke the ASP.Net Core integration out into its own library, Jasper.Http. SeeAdding Jasper to an ASP.Net Core Application in the docs for the details.

    We’ve gone back and forth on whether Jasper is going to be modular or an easier to work with single library, but this one came down to the ASP.Net Core bootstrapping being somewhat expensive and making the main Jasper test suite be unnecessarily slow, so out it goes. I don’t think you’re going to notice the hit if all you do is bootstrap a single application in a test suite, but you sure do if you’re developing on Jasper itself and bootstrap and tear down 100+ applications during the integration tests;-)

  • The “outbox pattern” support was extended to cascading messages. This was an overdue improvement over its FubuMVC/FubuTransportation/RhinoServiceBus ancestors. I’ll have a blog post about this next week after every one is back from the MVP Summit.
  • IServiceBus was renamed to IMessageContext. This one will make a lot more sense with some documentation or a blog post on the outbox pattern work.
  • (Hopefully) Easier messaging support configuration. I tried hard to simplify the API underneath

Next Up…

Jasper is getting put into a production application at work within the month, and we’re doing some significant proof of concept work around using Consul for service discovery with Jasper applications and building out Octopus deployment steps for the dynamic subscriptions. Next week I’ll get back to blogging about Jasper’s integration with ASP.Net Core applications, the new HTTP transport option, and Jasper’s support for the “outbox” pattern.

Renaming BlueMilk to Lamar

BlueMilk was the early working name of a successor project to StructureMap that was originally ripped out of the new Jasper framework project. 

Most of the feedback on the name “BlueMilk” wasn’t positive. I wasn’t terribly attached to the name, so I’m officially renaming “BlueMilk” to “Lamar.” The first Nuget (v0.8) is published with the very latest work. I might be able to throw an OSS Friday sometime this week at finishing the remaining StructureMap features inside of Lamar and publishing some documentation, but we’ll see.

First, what the heck is Lamar? For most of you, it’s my intended successor to the venerable, well liked (by at least some people), and unfortunately slowpoke StructureMap library. It’s also the runtime code generation and compilation subsystem I pulled out of Jasper so folks could use that independently of Jasper.

For the moment, you can find way more information about Lamar under the “BlueMilk” tag on my blog.

What’s with the new name?

Other than Marten, most of my OSS efforts the past 2-3 years have really been working toward the Jasper framework we’re brewing up at work as a successor to FubuMVC. “Jasper” itself is just named after my ancestral hometown (Jasper, MO), and most of the other projects on the JasperFx organization are named after either other little towns around Jasper (Oakton, Alba) or local landmarks (Baseline). Fitting into that theme, Lamar is the next town up highway 71 and I’ve got plenty of family roots there as well.

Other notes that may only interest me:

  • Mirabeau B. Lamar was the 2nd president of the Republic of Texas, a hero of the TX revolution, and worlds of things in Texas are named after him. I didn’t know this until researching this post, but Lamar, MO is apparently named after him as well.
  • My wife is *this* close to completing a master’s program at Lamar University and I’m super proud of her
  • Lamar the town is the birthplace of Harry S. Truman
  • It was raided during the Civil War by Quantrill’s Raiders (think Jesse James)
  • Wyatt Earp was their first constable
  • I’m biased, but the Barton County Fair in Lamar may be the best small town fair in the entire state
  • If you’re a Modern Family friend, the Cameron character is supposedly from this area