In NServiceBus 3 it was possible to implement the IBus interface. After upgrading to NServiceBus 5 it no longer seems possible.
IBus.InMemory is a member of the IBus interface and has the type IInMemoryOperations. IInMemoryOperations is marked as obsolete.
Considering the conditions above, it does not seem possible to implement IBus since it has member of type, which is obsolete. Am I missing something?
Can it be that you have enabled warnings as errors enabled in your project?
You can disable that by disabling that specific compiler warning:
#pragma warning disable 618
public IInMemoryOperations InMemory { get; }
#pragma warning restore 618
The InMemory Bus functionality was removed in version 5 http://docs.particular.net/nservicebus/upgrades/4to5#inmemory-removal
So no it is not recommended that people implement it
Related
I'm in a situation where the implementation of a library we are using is newer than the implementation one of our dependencies was coded against. E.g. Dependency uses MyLibrary-1.0 and we're using MyLibrary-2.0.
In the newer implementation a deprecated method has been removed, which causes run-time errors for us.
I'm trying to use AOP (Spring-AOP to be specific) to intercept calls made to the missing method, and proxy them into an existing method... but I can't seem to get the Aspect right.
It feels like Java is raising the 'java.lang.NoSuchMethodError' exception before my Aspect has an opportunity to intercept. Is there some trick I'm missing, or is this just not feasible (e.g. the method must exist in order to aspect it)?
#Before("execution(* com.mylibrary.SomeClass.*(..))")
Fails with java.lang.NoSuchMethodError
#Around("target(com.mylibrary.SomeClass) && execution(* missingMethod(..))")
Fails with java.lang.NoSuchMethodError
Assuming that your are talking about a 3rd party library which is independent of Spring, you cannot use Spring AOP with its proxy-based "AOP lite" approach which only works for public, non-static methods of Spring components. Please use the more powerful AspectJ instead. The Spring manual explains how to integrate full AspectJ with load-time weaving (LTW) into Spring applications. If your application is not based on Spring so far and you just wanted to use the framework because of Spring AOP, you can skip the whole Spring stuff altogether and use plain AspectJ.
The feature you want to use is an inter-type declaration (ITD), more specifically AspectJ's ability to declare methods for existing classes. Here is some sample code:
3rd party library:
package org.library;
public class Utility {
public String toHex(int number) {
return Integer.toHexString(number);
}
// Let us assume that this method was removed from the new library version
/*
#Deprecated
public String toOct(int number) {
return Integer.toOctalString(number);
}
*/
}
Let us assume that the method I commented out was just removed from the latest version your own project depends on, but you know how to re-implement it.
Project dependency depending on old version of 3rd party library:
package com.dependency;
import org.library.Utility;
public class MyDependency {
public void doSomethingWith(int number) {
System.out.println(number + " in octal = " + new Utility().toOct(number));
}
}
Because the previously deprecated method Utility.toOct does not exist anymore in the version used by your own project, you will get NoSuchMethodError during runtime when calling MyDependency.doSomethingWith.
Your own application:
package de.scrum_master.app;
import org.library.Utility;
import com.dependency.MyDependency;
public class Application {
public static void main(String[] args) {
System.out.println("3333 in hexadecimal = " + new Utility().toHex(3333));
new MyDependency().doSomethingWith(987);
}
}
As you can see, the application also uses the same library, but a different method which still exists in the current version. Unfortunately, it also uses the dependency which relies on the existence of the removed method. So how should we repair this?
Aspect using ITD:
AspectJ to the rescue! We just add the missing method to the 3rd party library.
package de.scrum_master.aspect;
import org.library.Utility;
public aspect DeprecatedMethodProvider {
public String Utility.toOct(int number) {
return Integer.toOctalString(number);
}
}
If you compile this project with the AspectJ compiler Ajc, it just works. In your real life scenario, compile the aspect into its own aspect library, put the weaving agent aspectjweaver.jar on the JVM command line in order to activate LTW and enjoy how it weaves the method into the library class via byte code instrumentation during class-loading.
Log output:
3333 in hexadecimal = d05
987 in octal = 1733
Et voilà! Enjoy. :-)
When the JVM load a class, it resolves all dependencies in a "linker" phase : external classes, properties and method. You can't pass this phase in your case, because methods are missing.
There are two modes on (Spring-)AOP: Proxy, and weaving.
Proxy create... a proxy around a class: the targeted class must exist and be loaded
Weaving can happen before a class is loaded: when a classloader load a class, an array of byte[] is passed to the weaver, which can manipulate the class bytecode before the class is really reified. This type of aop can work in your case. However, it will not be an easy task.
In the mono project documentation this limitation is outlined:
Limitation: Generic Interface Instantiation
The following class of interface dispatch is not supported in FullAOT
mode:
interface IFoo<T> {
...
void SomeMethod ();
}
Since Mono has no way of determining from the static analysis what
method will implement IFoo.SomeMethod this particular pattern is
not supported.
We have been using code like this unbeknownst to this limitation, and are currently attempting to figure out if some stability issues and this are related. This seems to function as expected, and so we are skeptical this is an issue still. Our code compiles to AOT with no errors, and runs without throwing any errors. Is this just old documentation?
An added bonus question: If this isn't supposed to work...why does it work for the built-in C# classes such as IList without issue but it shouldn't work otherwise?
I have been trying to use protobuf-net with MonoTouch but I have no idea how, and despite having heard that it is possible, I haven't been able to find any tutorial or any example that actually work.
It was confirmed by Marc Gravell on his blog that it does work on MonoTouch. I have also looked through the blogs of the two people he states in this article, but I haven't found anything related to protobuf.
Having no lead on the subject, i decided to download protobuf-net and try it out anyway. So I created the following object for testing purposes :
[ProtoContract]
public class ProtoObject
{
public ProtoObject()
{
}
[ProtoMember(1)]
public byte[] Bytes { get; set; }
}
and I tried to send it through WCF from a service running on windows using a [ServiceContract] interface with
[OperationContract]
ProtoObject GetObject();
but the instance of ProtoObject recieved on the device is always null. This is not really unexpected since i have read that to make protobuf-net work with WCF you need to modify the app.config/web.config.
It's a little hard to accomplish since a MonoTouch project has no app.config, but I did not yet give up. To replace the app.config, I tried to add the ProtoEndpointBehavior to the client's endpoint's behaviors programmatically, and there I hit a wall. ProtoBuf.ServiceModel.ProtoEndpointBehavior, available on .NET 3.0 implementation of protobuf-net is not available on the iOS release.
How would I go about using protobuf-net to deserialize objects received from a windows-based WCF endpoint using protobuf-net serialization.
It is actually pretty much the same as described in this blog entry by Friction Point Studios. Since meta-programming on the device is not really an option, the trick is to pre-generate a serialization dll. This can be done by creating a small console exe (this is just a tool - it isn't designed to be pretty) that configures a RuntimeTypeModel (by adding the types you are interested in), and then call .Compile(...):
var model = TypeModel.Create();
model.Add(typeof (ProtoObject), true);
model.Compile("MySerializer", "MySerializer.dll");
This generates a serializer dll; simply reference this dll (along with the iOS version protobuf-net), and use the serializer type in the dll to interact with your model:
var ser = new MySerializer();
ser.Serialize(dest, obj); // etc
Just to bring this up to date there are a few issues with using WCF + Protobuf on MonoTouch. As you have observed the current releases of System.ServiceModel and protobuf light for ios don't include all the necessary bits.
However if you go and get the full System.ServiceModel from the Mono repository on GitHub and build it against the full Protobuf source then you can get it to work; I have done so.
You need to generate a serialisation assembly using the precompile tool then edit the ProtoOperationBehavior attribute to give it some way to reference your serialisation assembly. All the changes are too extensive to document here but it can be done and it is a lot faster than DatacontractSerializer which is pretty awful on iOS.
Simple question... I want to use Ninject Interceptors to take care of my NFRs, however alot of my classes require arguments in the constructors. I read that they are looking at allowing constructors with arguments but currently I get an error:
Can not instantiate proxy of class: myClass
Could not find a parameterless constructor.
Parameter name: constructorArguments
I am using version 2.2.1 I think, noticed there is a tagged 2.3 version on the extensions site, but will any of this solve my problems? if not is there any way around this?
2.3 adds support for Interface proxies. This means it will solve the problem for all types that are resolved by interface. It's also planned to add support for classes without default constructor.
But be aware that 2.3 is work in progress. While there aren't any known new problems it is not tested yet against real applications as 2.2 is and interface changes of new stuff can still change. Also InRequestScope support for XML and Conventions has temporarily been disabled.
Anyone had any luck integrating StructureMap (DI Framework) with WCF?
I can return the default instance in the constructor of my WCF service like this, but obviously it is not ideal.
public MemberService()
{
this.memberRepository = StructureMap.ObjectFactory.GetInstance<IMemberRepository>();
}
I have seen this (http://www.lostechies.com/blogs/jimmy_bogard/archive/2008/07/29/integrating-structuremap-with-wcf.aspx) but have not had luck setting it up as I think it's incompatible with the latest 2.5+ release of StructureMap.
This has already been discussed here. What issues did you encounter with the example you provided? Instead of writing the code in the constructor of the service you write it in the GetInstance method of your IInstanceProvider implementation.