When I'm migrating the .net core application from 2.0 to 3.1, the following method services.AddCookieTempData() is not working since it's referring assembly"AspNetCore.Mvc.CookieTempData". If we comment this code it's showing the below error message. Please let us know what is the alternate for this method.
public void ConfigureServices(IServiceCollection services)
{
services.AddCookieTempData();
Error Message:
The 'Microsoft.AspNetCore.Mvc.ViewFeatures.Infrastructure.DefaultTempDataSerializer' cannot serialize an object of type
Your question seems similar to what is reported at https://github.com/aspnet/Mvc/issues/6711. On that page, Elion writes, "TempData serializer currently supports only a limited set of data types for simplicity. It supports a few primitive types such as int, string, and bool, and simple containers of those types, such as lists."
That same page points to a work-around at Store complex object in TempData. hem's highly-upvoted answer there (https://stackoverflow.com/a/35042391/2615878) recommends using an extension method and provides sample code for such.
Related
so I was playing a bit with Mapstruct, reading the reference Documentation for the Version 1.1.0.Final, and arrived at the point:
implicit type conversions
where is defined the following statement:
Between JAXBElement < T> and T
I tried that, but the error what I received was:
Can't map property "java.lang.String xmlElement" "javax.xml.bind.JAXBElement<java.lang.String> xmlElement".
Consider to declare/implement a mapping method:
javax.xml.bind.JAXBElement<java.lang.String> map(java.lang.String value)".
I know thisi is the same thread asCan't map property when using MapStruct but since then Mapstruct released a new version.
Am I doing something wrong or this feature really is missing?
Thank you.
Mapping from JAXBElement<T> to T works out of the box. For the reverse you need to make sure that the ObjectFactory(ies) are in the Mapper#uses, MapStruct uses those methods to create the types.
You can also have a look at this integration test.
In case this happens on Java 9 or higher and you use implementation of type JAXBElement from maven library (in my case'javax.xml.bind:jaxb-api') make sure it is on the classpath of the annotation processor - this resolved the issue for me.
If your JAXBElement was generated by a wsdl client generator (eg. xjc) you need to provide the corresponding ObjectFactory.class generated by the client generator:
#Mapper(uses = ObjectFactory.class)
public interface OrderMapper {
Order orderEntityToExternalOrder(OrderEntity orderEntity);
}
See:
MapStruct 1.0.0.Beta1 is out with JAXB support, custom factories, decorators and more
Hi I am trying to learn JAVA deeply and so I am digging into the JDK source code in the following lines:
URL url = new URL("http://www.google.com");
URLConnection tmpConn = url.openConnection();
I attached the source code and set the breakpoint at the second line and stepped into the code. I can see the code flow is: URL.openConnection() -> sun.net.www.protocol.http.Handler.openConnection()
I have two questions about this
First In URL.openConnection() the code is:
public URLConnection openConnection() throws java.io.IOException {
return handler.openConnection(this);
}
handler is an object of URLStreamHandler, define as blow
transient URLStreamHandler handler;
But URLStreamHandler is a abstract class and method openConnection() is not implement in it so when handler calls this method, it should go to find a subclass who implement this method, right? But there are a lot classes who implement this methods in sun.net.www.protocol (like http.Hanlder, ftp.Handler ) How should the code know which "openConnection" method it should call? In this example, this handler.openConnection() will go into http.Handler and it is correct. (if I set the url as ftp://www.google.com, it will go into ftp.Handler) I cannot understand the mechanism.
second. I have attached the source code so I can step into the JDK and see the variables but for many classes like sun.net.www.protocol.http.Handler, there are not source code in src.zip. I googled this class and there is source code online I can get but why they did not put it (and many other classes) in the src.zip? Where can I find a comprehensive version of source code?
Thanks!
First the easy part:
... I googled this class and there is source code online I can get but why they did not put it (and many other classes) in the src.zip?
Two reasons:
In the old days when the Java code base was proprietary, this was treated as secret-ish ... and not included in the src.zip. When they relicensed Java 6 under the GPL, they didn't bother to change this. (Don't know why. Ask Oracle.)
Because any code in the sun.* tree is officially "an implementation detail subject to change without notice". If they provided the code directly, it helps customers to ignore that advice. That could lead to more friction / bad press when customer code breaks as a result on an unannounced change to sun.* code.
Where can I find a comprehensive version of source code?
You can find it in the OpenJDK 6 / 7 / 8 repositories and associated download bundles:
http://hg.openjdk.java.net/jdk6/jdk6 - http://download.java.net/openjdk/jdk6/
http://hg.openjdk.java.net/jdk7/jdk7 - http://download.java.net/openjdk/jdk7/
http://hg.openjdk.java.net/jdk8/jdk8
Now for the part about "learning Java deeply".
First, I think you are probably going about this learning in a "suboptimal" fashion. Rather than reading the Java class library, I think you should be reading books on java and design patterns and writing code for yourself.
To the specifics:
But URLStreamHandler is a abstract class and method openConnection() is not implement in it so when handler calls this method, it should go to find a subclass who implement this method, right?
At the point that the handler calls than method, it is calling it on an instance of the subclass. So finding the right method is handled by the JVM ... just like any other polymorphic dispatch.
The tricky part is how you got the instance of the sun.net.www.protocol.* handler class. And that happens something like this:
When a URL object is created, it calls getURLStreamHandler(protocol) to obtain a handler instance.
The code for this method looks to see if the handler instance for the protocol already exists and returns that if it does.
Otherwise, it sees if a protocol handler factory exists, and if it does it uses that to create the handler instance. (The protocol handler factory object can be set by an application.)
Otherwise, searches a configurable list of Java packages to find a class whose FQN is package + "." + protocol + "." + "Handler", loads it, and uses reflection to create an instance. (Configuration is via a System property.)
The reference to handler is stored in the URL's handler field, and the URL construction continues.
So, later on, when you call openConnection() on the URL object, the method uses the Handler instance that is specific to the protocol of the URL to create the connection object.
The purpose of this complicated process is to support URL connections for an open-ended set of protocols, to allow applications to provide handlers for new protocols, and to substitute their own handlers for existing protocols, both statically and dynamically. (And the code is more complicated than I've described above because it has to cope with multiple threads.)
This is making use of a number of design patterns (Caches, Adapters, Factory Objects, and so on) together with Java specific stuff such as the system properties and reflection. But if you haven't read about and understood those design patterns, etcetera, you are unlikely to recognize them, and as a result you are likely to find the code totally bamboozling. Hence my advice above: learn the basics first!!
Take a look at URL.java. openConnection uses the URLStreamHandler that was previously set in the URL object itself.
The constructor calls getURLStreamHandler, which generates a class name dynamically and loads, and the instantiates, the appropriate class with the class loader.
But URLStreamHandler is a abstract class and method openConnection()
is not implement in it so when handler calls this method, it should go
to find a subclass who implement this method, right?
It has to be declared or abstract or implemented in URLStreamHandler. If you then give an instance of a class that extends URLStreamHandler with type URLStreamHandler and call the openConnection() method, it will call the one you have overriden in the instance of the class that extends URLStreamHandler if any, if none it will try to call the one in URLStreamHandler if implemented and else it will probably throw an exception or something.
Was wondering if there's a way one can handle conversion errors in a lenient way.
Given a query that returns a List[ModelObject]
If there are 5 DBObjects retrieved, one of them is throwing a ConversionException when converted to ModelObject, is there a way to return the 4 convertible objects and provide a hook for the 1 conversion failure?
A bit late, but this answer might help someone else's search
I agree it would be nice to do this on a policy basis - at the moment, if you get a single conversion error, you get no list at all. I think there are use cases where this is a valid need.
However, since you can't, you need to register a custom converter for your ModelObject that converts leniently...
public class DBObjectToModelObjectConverter implements Converter<DBObject,ModelObject>{
public ModelObject convert(DBObject s) {
... Read from the DBObject into your ModelObject and work around the bad data
}
}
and then register this as a custom converter in your bean definitions. Something like:
<bean id="lenientModelReadConverter" class="com.my.DBObjectToModelObjectConverter"/>
<mongo:custom-converters>
<mongo:converter ref="lenientModelReadConverter"/>
</mongo:custom-converters>
Is there any way to create a fake from a System.Type object in FakeItEasy? Similar to:
var instance = A.Fake(type);
I try to write a fake container for AutoFac that automatically return fakes for all resolved types. I have looked in the code for FakeItEasy and all methods that support this is behind internal classes but I have found the interface IFakeObjectContainer that looks pretty interesting, but the implementations still need registration of objects that is the thing that I want to come around.
As of FakeItEasy 2.1.0 (but do consider upgrading to the latest release for more features and better bugfixes), you can create a fake from a Type like so:
using FakeItEasy.Sdk;
…
object fake = Create.Fake(type);
If you must use an earlier release, you could use some reflection based approach to create a method info for the A.Fake() method. (since it's about auto mocking this shouldn't be a problem really).
This is best done using a registration handler. You should look into how AutofacContrib.Moq implements its MoqRegistrationHandler. You'll see that it is actually using the generic method MockRepository.Create to make fake instances. Creating a similar handler for FakeItEasy should be quite simple.
In my app I use JsArray extensively to store my overlay types. I use java.util.List to store my client-side Java POJOs.
For performance reasons and to unify the way I access my model I planned to eliminate the Lists and use only JSO wrappers. Given a wrapper around a native array that can store any Java Object:
public class JsArrayObject<T> extends JavaScriptObject {
protected JsArrayObject() {}
public final native T get(int index) /*-{
return this[index];
}-*/;
public final native void push(T value) /*-{
this[this.length] = value;
}-*/;
}
Is it safe to store Java Objects this way? The doc says that when you pass a Java Object into JavaScript the result is "an opaque value accessible through special syntax". This sounds confussing to me. For instance if I push an Integer and try to get it an exception will be thrown because something different than an Object was found (at least in dev mode). The same happens with the rest of Java primitive Wrappers. Apart from the problems with Java primitive Wrappers, are there other concerns to be aware?
Many thanks
Which doc are you referring to? The one on this page?
They're talking in terms of passing Java objects into JavaScript with the intent of having JavaScript code use the methods or fields in the object. It is possible to do that, but the syntax you have to use on the JavaScript side is a bit awkward. If you've done any JSNI, you've seen it.
If you don't intend to access the Java objects from the JavaScript side you can ignore the business about the special syntax. So yes, it is safe. I'd be interested to know if it actually turns out to help performance.