Whats the lifestyle of the implicit delegate-factory in the TypedFactoryFacility? Since the components created by the factory are released when the factory is released I am guessing that it registers as transient, but can anyone please confirm this?
Yes, they are registered as transient.
Related
As an example (and the reason of my question), the class Windows.XAML.Media.Transform, as far as I can see from the WinMD info shown by ILDASM, has no defined constructor.
But if I try to derive from that class, on my C# project, compiler complains that non constructor can be found.
This seems to me that this could be a result of hidden visibility of the constructor.
A same effect can be achieved in C# declaring a private (or internal) Constructor, but it must be declared, otherwise a public constructor is created by the compiler, and the class is indeed derivable.
Any hint?
I think what's going on here is, that the class has explicitly declared an internal (default) constructor, no public constructor(s), so the developers can inherit from the class within the defining assembly. Everybody else, outside the assembly is prevented from beeing able to inherit from the class.
WinRT is an evolution of the COM concepts and is a quite different story as we are talking about binary components and not source inheritance.
The most important thing in this ABI story is that the only things of the component that can be used are the ones exposed via interfaces.
Constructors cannot be defined in interfaces nor can statics, and this means that WinRT need interfaces for these too.
C# viewes of WinRT components are an artifact of the language projection and not the real layout of the component.
To fully understand what's there, you should look at the component in C++, using the native library WRL that is the library used to build the WinRT APIs.
The Constructor is a projection for the factory interface of the WinRT component (and statics, new to WinRT as they didn't exist in COM, have a similar treatment).
When you "new" from C# an object, a Factory component associated to the component is first created. After this the factory create the object.
For this reason the constructor question should be seen in terms of factory component and not in terms of constructor (that exist in the underlying implementation but it doesn't really matter as what you see of the component is only its binary contract, the ABI).
So there are different options:
1. A factory does not exist and you cannot create the component. If the Factory interface is internal you can't use it and can't create the object.
2. A factory exists and expose the default constructor. In C# you can new the object
3. A custom factory exists and expose custom constructors (whit parameters).
ITransformFactory is private and I believe this explain the behavior you have seen.
There is much more on this topic as WinRT aggregation is the way they provide binary inheritance and versioning, but this is another (very long) story.
Still digging, and never will stop, that's the fun part of our job :)
I have an Object that is reference by two other Objects
I use Jackson to serialize my objects but have found my shared object is duplicated rather than reference.
The reason is as I understand that Jackson can only serialize by value and not by reference.
I have unsuccessfully looked around for some recommended solution.
Any and all help is appreciated.
current Jackson Lib 1.8.3
Well time passed and Jackson 2.0 is out. Here is the requested feature ! I answer this so people like me coming after know its available
https://github.com/FasterXML/jackson-docs/wiki/Presentation-Jackson-2.0
Currently (1.9) you would have to write custom serializer, deserializer, to handle this. There is no out-of-the-box support for handling object identity.
Of Java frameworks the only one that I know to support object identities is XStream.
For what it is worth, there is a long-standing feature request for Jackson to add support. And there is reasonable chance this gets worked on for 2.0. But even if it will be, it'll take a while (a month or two).
UPDATE (April 2013): As per the other accepted answer, this feature -- #JsonIdentityInfo -- was indeed included in Jackson 2.0, and is available. No need for custom (de)serializers.
Is there any way to trace exactly what Castle Windsor is doing when resolving a type?
I am looking for a TraceSource name, or log4net (etc.) logger name. If this does not exist where is the best place to hook into the framework to provide my own logging code?
Reason being is we have deployed the exact same build/config of our software to two different virtual servers (both servers created from the same image), and one of them "works" and the other doesnt.
On the failing deployment, our own logs show that a component that was expected to be injected to another is null. On the other machine, the logs show everything is healthy.
I am lost as to why this might happen, and was looking to trace the castle container resolving code.
EDIT:
Running Castle Windsor Release 2.0 on .NET 3.5 SP1
Thanks.
You could try hooking to the kernel's DependencyResolving event:
container.Kernel.DependencyResolving += (componentModel, dependencyModel, dependency) => {};
Or adding a ISubDependencyResolver:
container.Kernel.Resolver.AddSubResolver(new MyDependencyResolver());
I was just reading a thread on SO that was discussing the merits of Singleton vs. Static Classes.
Some people mentioned that pattern X appeared to be more of a 'factory' rather than a Singleton 'pattern'.
What are the differences between a 'factory' and a 'design pattern'?
A "factory" is a specific design pattern:
http://en.wikipedia.org/wiki/Factory_method_pattern
Similarly "singleton" is also a design pattern:
http://en.wikipedia.org/wiki/Singleton_pattern
Factories and Singletons are some of the many design pattern.
A factory pattern can be implemented as a singleton pattern that produces objects. A factory could also be an instanced class, and therefore not a singleton. Likewise, a singleton can be a factory, but it can also be something else, like a global settings manager or event registry.
a 'factory' rather than a Singleton
'pattern'
Let me flesh that out and place the quotation marks correctly:
a 'factory pattern' rather than a 'singleton pattern'
Both are design patterns.
A Factory is a Design Pattern - not the other way around.
You got it slightly wrong. "Factory" is a pattern too and contrasts here with "Singleton".
'Factory' is a type of design pattern. You can see a couple examples of the Abstract Factory here or the Factory Method here based on the context
factory is a design pattern :-) as is Singleton. one could argue that singleton is kind of a factory. It creates an object when needed and uses a set chaching policy (which is always return the same object once it has been creaqted) but that's achedemic and would generally just be confusing in most debates about structure
A factory is a type of design pattern. Basically a factory returns a class dependant on the needs of the calling class. All classes returned by the factory should share the same interface so you can invoke the same public methods over them (although how each class implements the method may be different).
Here's a good link http://en.wikipedia.org/wiki/Factory_method_pattern
Lots of answers, but none seem to actually differentiate between the two patterns well. Let me try and see if I can't confuse issue more.
A Singleton is a pattern that restricts your system to creating only one instance of a given class. The restriction is usually implemented by creating a Factory that will either create an instance of the class (if none already exist) or return the already-created instance on subsequent calls.
A factory is used to create singletons and in other situations. It can be used to replace "new" in many cases. One advantage is that you can write your factory to allow the type of object to be returned to be "Set". This way your testing framework can "set" a mock object instead of the real one--and the rest of your system will then use the mock object.
Another case might be to have the factory evaluate from parameters which type to return, or from data (perhaps XML). They are also used to implement Dependency Injection where the factory looks at what you need and builds chains of objects to fulfill those needs.
It seems that current behaviour of Castle Windsor (2.0) method
container.ResolveAll(Type type)
is to ignore all services that cannot be resolved due to missing dependencies. What is recommened way to resolve all services + throwing exception when any of services cannot be resolved?
AFAIK there is no built-in way to do that and I've been thinking about implementing an option to throw instead of ignoring invalid components. However, this has some consequences that need to be thought through.
In the meantime, here's a hack. Let me know if it works for you.