3.0.0 Update

[Corey Kaylor]

-The changes for Rhino.Queues sending options have been pulled in.

-- Maximum retry count on send failure

-- Deliver by, if time is exceeded the message is discarded

-Removal of log4net in favor of Common.Logging

-Pulled in spelling error.

Ryan is looking into whether or not some or all of the sending options will work with the MSMQ transport as well.

Spring tests are not passing due to version conflict (I chose 2.1.1)

Marko, are you up for this or would a different version be better?

We will begin to incorporate these changes into our environment over the next week or two. Provided things are running smooth I will publish to nuget then.

[Marko Lahma]

I'll have a look wrt Spring problems. Hopefully tomorrow (Sunday). Latest Common.Logging is always the best option but need to check whether to use binding redirects or upgrade to Spring.NET 2.0 M1..

-Marko

[Corey Kaylor]

One quick update. Ryan was able to get some of the capabilities for delivery options DeliverBy, and MaxAttempts into the MsmqTransport. With the caveat that MaxAttempts must be one if used.

Marko, any progress on your end?

--
You received this message because you are subscribed to the Google Groups "Rhino Tools Dev" group.
To view this discussion on the web visit https://groups.google.com/d/msg/rhino-tools-dev/-/5-eRWeybbJYJ.
To post to this group, send email to rhino-t...@googlegroups.com.
To unsubscribe from this group, send email to rhino-tools-d...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/rhino-tools-dev?hl=en.

[Marko Lahma]

I investigated the matter  shortly last weekend (other things came to take some time) and we have two options:

* Plain assembly redirect (easy and quick, requires users the to know about it)

* Use Spring.NET 2.0 *nightly build*, M1 release hasn't for some reason signed dlls so they won't work with current requirements

Going for 3.x release a new and shine Spring.NET 2.0 sounds good, but will require users to use "experimental" (though it's solid).

What would be the path to take?

-Marko

[Corey Kaylor]

Honestly, I'm fine with whatever solution you choose. I don't have a large stake in Spring support, so I don't know if my opinion matters.

To view this discussion on the web visit https://groups.google.com/d/msg/rhino-tools-dev/-/shcEsaE3g-EJ.

[Jakub Berezanski]

Speaking of container updates, I've sent a pull request (https://github.com/hibernating-rhinos/rhino-esb/pull/56) with Windsor updated to 3.1. It would be nice if this made it into the release - I would like to use the newest Windsor in my apps and I don't like binding redirects.

[Corey Kaylor]

Shouldn't be a problem to get it in. Sounds like we will also be breaking out the dependency on RhinoQueues into a separate nuget package.

To view this discussion on the web visit https://groups.google.com/d/msg/rhino-tools-dev/-/a74fHX88GOkJ.

[Michael Lyons]

Just thought I might add to the conversation.

I've started prototyping an implementation for future RabbitMQ support.

So far the IOneWayBus is in with IMessageBuilder implemented. Currently working on ISubscriptionStorage and ITransport implementations.

I'm still trying to wrap my head around how the internals exactly work and I'm doing a lot of cross referencing and adapting from MSMQ.

At the moment I've made RabbitMQ a dependency, it will need to be broken off into a separate package as per the strategy with RhinoQueues.

I'll keep you updated.

[Corey Kaylor]

Great news, I know others have wanted a RabbitMQ transport. It should also help others tackling similar transports. 

There are lots of great things trickling in. I should be able to get to all of the pull requests this week as well.

To view this discussion on the web visit https://groups.google.com/d/msg/rhino-tools-dev/-/X7-ClMAvQ2wJ.

[Corey Kaylor]

I have pulled in all but one pull request. After that one gets pulled in I will run things on our end for a week and then publish the 3.0.0 nugets if everything is running ok. You of course don't have to wait on me if you want to pull them from the teamcity artifacts. I haven't yet tagged them as 3.0.0 yet though.

[Jakub Berezanski]

What's the status on the nuget packages? Are there any problems holding up the publication?

 

(I'm eager to use the new features of 3.0 without needing to do a custom build.)

[Corey]

Everything is going very well and at least with the SM container we don't seem to be having any issues. I want to follow up with one other thread and am toying with one minor serialization change (although a breaking change if you implemented your own serializer, not in the wire format) *maybe* before I publish. If I'm lucky it would be before the end of the week.

[ozanyurt]

Can we use RabbitMQ just like RQ. I mean do I need to install rabbitMQ to client machine like MSMQ?

[Corey Kaylor]

RabbitMQ has still not been implemented to my understanding. The transports have been broken out into separate assemblies to make that type of addition less intrusive.

To view this discussion on the web visit https://groups.google.com/d/msg/rhino-tools-dev/-/6nshqjIxcpQJ.

[Corey Kaylor]

I have just pushed out the 3.0.0 nugets. I held off on the serialization changes I mentioned previously. I will have a blog post Monday detailing how to update.

[Michael Lyons]

Hi guys.

No I have not completed the initial version of the rabbit mq transport.

I'm finding it quite a challenge since RabbitMq seems to already have it's own kind of service bus idealogy which doesn't translate cleanly or it might just be my understanding of rsb that I'm having issues with.

It also doesn't help that I've had limited time to work on it.

[Corey]

I have written up some of the highlights of the 3.0.0 release. Apologies with my blog still going through changes, if you notice oddities, just ignore. :)

http://coreykaylor.com/blog/2012/10/15/rhino-servicebus-3-0-0-update/

[miles]

Great work Corey, I just upgraded today and it's all working nicely.

One potential gotcha that I found is that now, with the transports now in separate assemblies, if you just install the package "Rhino.ServiceBus", you don't get a working installation like you used to - you need to use the "Rhino.ServiceBus.RhinoQueues" package instead.  This is different from all the getting started tutorials that come up if you search for RSB.  

Pretty trivial to sort out, but might be confusing for newcomers, so I thought I'd note it.

Cheers,

Miles

[Jakub Berezanski]

Only the Rhino Queues transport has been moved to a separate assembly. The main package still contains a fully functional MSMQ transport.