Which GSON version does Retrofit 1.9.0 contain? I'm having few issues with GSON while deserialising values (when they are null). So before i can start debugging, i just wanted to know about the GSON version.
Retrofit 1.9.0 comes with Gson of version 2.3.1. you can get the source code of retorift 1.9.0 here. go through the source code and you can see the Gson version used.
you can find this in the maven file.
<gson.version>2.3.1</gson.version>
hope it helps
Related
I am attempting to upgrade from Wicket 9.0.0 to Wicket 9.3.0. When I change the version in a quick-start application, everything is fine.
The problem occurs in my real application, where we were originally using Jakarta Enterprise Beans 8.0.0. At runtime, when a database access was attempted, we got an exception with the following message:
Last cause: net.sf.cglib.proxy.MethodInterceptor not found by org.objectweb.asm [23]
Trying to use Jakarta EE 9.1 instead
I changed my pom.xml as follows:
<jakartaee>9.1.0</jakartaee>
<wicket.version>9.3.0</wicket.version>
I downloaded the jar for Jakarta EE 9.1, changed "javax" to "jakarta" throughout my application, rebuilt it and tried to run again.
The result was still not perfect, but significantly better than before: a plain old null pointer exception instead of any weird errors about cglib.
Here's the section of code that now causes the trouble:
#EJB(name = "AdminNotesFacade")
private AdminNotesFacade adminNotesFacade;
public AdminNotesFacade getAdminNotesFacade() {
return adminNotesFacade; //ACTUALLY RETURNS NULL
}
So now the big question is: what do I need to do/change to make the #EJB work instead of returning null?
Checking the Payara log, I get this error:
java.lang.RuntimeException: Unable to load the EJB module. DeploymentContext does not contain any EJB. Check the archive to ensure correct packaging for D:\Dev\icase2\target\icase2.
If you use EJB component annotations to define the EJB, and an ejb or web deployment descriptor is also used, please make sure that the deployment descriptor references a Java EE 5 or higher version schema, and that the metadata-complete attribute is not set to true, so the component annotations can be processed as expected
at org.glassfish.ejb.startup.EjbDeployer.prepare(EjbDeployer.java:189)
Adding further details, 2022-05-06
I wonder if we were going off on the wrong track when we thought that we could fix this by upgrading our jakartaee version. From Wicket 9.0 to 9.3 is only a change of minor version and you wouldn't expect to have to make such fundamental changes to get a minor upgrade working.
I've tried using Wicket 9.9.1 instead, in case this problem has been fixed in more recent versions, but it's exactly the same.
Anyway, I have created a very small "quick-start" application, based on Wicket's own templates, to reproduce the problem. I have stuck with the original "javax" version, and added just one EJB - a JavaMail bean. I think it's probably interesting to know that it's not a specifically database-related issue. We just can't seem to load any EJBs at all.
In the Wicket 9.0.0 version, a simple form is displayed on the home page, allowing the user to enter their email address. When they submit the form, a test message is sent to that address. It works fine.
Then if I change the Wicket version to 9.3.0 but make no other changes at all, it doesn't even get to the stage of displaying the home page, it immediately crashes with the message "Last cause: net.sf.cglib.proxy.MethodInterceptor not found by org.objectweb.asm [23]"
For what it's worth, here's the code that triggers the error.
public class HomePage extends WebPage {
#EJB(name = "EmailerFacade")
private EmailerFacade emailerFacade;
private static final long serialVersionUID = 1L;
private String sendTo = "";
public HomePage(final PageParameters parameters) {
super(parameters);
add(new Label("version", getApplication()
.getFrameworkSettings().getVersion()));
FeedbackPanel feedback = new FeedbackPanel("feedback");
add(feedback);
final Form emailForm = new Form("emailForm") {
#Override
protected void onSubmit() {
emailerFacade.sendMessage(sendTo, "Test message from quick-start",
"Version is " + getApplication().getFrameworkSettings()
.getVersion());
info("Tried to send message to " + sendTo);
}
};
add(emailForm);
final TextField<String> emailAddress = new TextField<>("emailAddress",
new PropertyModel<>(this, "sendTo"));
emailAddress.setLabel(Model.of("Email address"));
emailAddress.setRequired(true);
emailForm.add(emailAddress);
}
}
Wicket 9.x is based on javax.servlet APIs. To deploy it on jakarta.servlet supporting web container you will need to migrate the bytecode with a tool like https://github.com/apache/tomcat-jakartaee-migration.
I am not sure whether Payara does something smart at runtime to support both javax.** and jakarta.** classes.
Tomcat 10.x supports migration of the classes at application start time by deploying your app in the special $CATALINA_HOME/webapps-javaee folder.
This answer was actually provided by Sven Meier. He commented:
Use the new system property to switch to ByteBuddy in Wicket 9.x:
-Dwicket.ioc.useByteBuddy=true
To expand a bit on this, I found I needed to do three things:
Set the system property "wicket.ioc.useByteBuddy" to true as specified by Sven
Add a dependency on byte buddy
Upgrade to a higher version than I was initially attempting to do: 9.3.0 was not good enough. I see in a comment above by Sven, he says that the migration to byte buddy was actually done in 9.5. So in fact I upgraded to the latest version, which is currently 9.9.1.
Here is the dependency on byte buddy that I added:
<dependency>
<groupId>net.bytebuddy</groupId>
<artifactId>byte-buddy</artifactId>
<version>1.12.10</version>
</dependency>
My spring web application is using servlet api 2.5 along with spring framework 4. Its deployed in tomcat 9. Its working fine. I am not sure why tomcat is not complaining about it as it needs servlet api 4 as per documentation. Is it backward compatible or spring is doing some magic? Just for clarity We are using interfaces from servlet api 2.5 in our code which should not compile with servlet api 4. It is compiling because we are compiling with 2.5 but we are expecting it to fail at runtime in tomcat. Thanks
Are you using methods/classes that no longer exist in servlet spec 4? There isn't magic - it's downward compatible. If you tried to run, for example, AsyncEvent code in Tomcat 5.5 (servlet spec 2.4) then yes, you'd have a problem. But running old code on a new server - without using things that have totally changed or disappeared - is rarely a problem.
EDIT
You said that the "old" code has:
Map parameterMap = request.getParameterMap();
This is still valid if not best practice. With newer compilers you may get a warning from the compiler that you are not using generics but it is still valid. And since the Javadocs from that time say:
Returns: an immutable java.util.Map containing parameter names as keys and parameter values as map values. The keys in the parameter map are of type String. The values in the parameter map are of type String array.
So your old code must be casting the keys as a String and the values as a String[] - just like the newer code that would be:
Map<String, String[]> parameterMap = request.getParameterMap();
Both versions will compile in recent versions of the compiler though, again, you may get warnings with the code that doesn't take advantage of generics.
The key is the use of generics - the <String, String[]> part. It's clearer code when using generics and the compiler can help with issues. With the non-generics version you could have tried to cast the key in the map to any object. It would compile but at runtime you'd likely get a ClassCastException.
From the perspective of Tomcat it's still returning the same thing.
Is that clearer?
Using the cosmos db sdk in a 1.0 function. UpsertDocumentAsync throws error "PartitionKey extracted from document doesn't match the one specified in the header". In my REST Api using the same cosmos db sdk v2.1.3 everything works fine. Only difference in packages is Newtonsoft.Json is version 10.0.2 in function and version 11.0.2 in REST Api. I'm wondering if it has something to do with Netwonsoft and the sdk usage of it may differ between versions. Anyone else having this issue that can shed some light?
It was indeed Json.net. I was upgrading to Azure Function 2.0 and it uses 11.0.2 version. So upgrading my other components to the newest version fixed the issue. Thank you for your quick reply.
I have an old Asp.Net web application using Unity for dependency injection.
Today I updated the Unity using NuGet to the latest version. On trying to run the application, I am getting an exception:
Unity.Exceptions.ResolutionFailedException: 'Resolution of the dependency failed, type = 'SOME.Services.ISomeService', name = '(none)'.
Exception occurred while: while resolving.
Exception is: InvalidOperationException - The property converter on type DAL.Repositories.SomeRepository is not settable.
The exception happened on line
_someService = container.Resolve<ISomeService>();
I am very new to Unity. Could you please help?
The newer versions of Unity have breaking changes.
You may want to stick with the older versions of the DLL until you refactor the changes.
v4.0.1 Version 4.x is dead. Loss of original signing certificate made
it impossible to release anything compatible with v4.0.1 release. To
give original developers a credit only about 60 issues were found
during two years in production. To move on and enable further
development version v5 has been created.
v5.x Version 5.x is created as replacement for v4.0.1. Assemblies and
namespaces are renamed and refactored but otherwise it is compatible
with the original. v5.0.0 release fixes most of the issues found in
v4.0.1 and implements several optimizations but the accent was on
compatibility and if optimization would break API it was omitted. Once
stabilized, this version will enter LTS status and will be patched and
fixed for the next few years. There will be no significant development
in this line.
Check their road map here.
At the moment, the Hibernate Validator has released the latest version as 4.3.0.Final here. I have tried to upgrade it to my Glassfish 3.1.2 as the following step: -
1. Remove the GLASSFISH/glassfish/modules/bean-validator.jar
2. Copying the hibernate-validator-4.3.0.Final.jar to GLASSFISH/glassfish/modules
3. Restart the Glassfish
4. The Glassfish cannot start. It seems hang.
After searching via the Google, I've found that the file named "bean-validator.jar" was created by the Glassfish team as an OSGi version. Sadly, I cannot find how to create it. Could you please help to advise further? Thank you very much for your help in advance. I'm looking forward to hearing from you soon.
A (slightly outdated) description of how to build Glassfish's bean-validator.jar can be found here.
What's needed in general is an OSGi bundle which includes Hibernate Validator itself and the Bean Validation API. With this bundle you should be able to replace the original bean-validator.jar. Additionally you need the JBoss Logging bundle, which is used since release 4.3 by Hibernate Validator as logging API and already comes in form of an OSGi bundle.
If you're building a web application, you could also package HV 4.3 within your WAR and turn off class loader delegation by providing the file WEB-INF/glassfish-web.xml with the following contents:
<!DOCTYPE glassfish-web-app PUBLIC "-//GlassFish.org//DTD GlassFish Application Server 3.1 Servlet 3.0//EN" "http://glassfish.org/dtds/glassfish-web-app_3_0-1.dtd">
<glassfish-web-app>
<class-loader delegate="false" />
</glassfish-web-app>
That way the HV classes will be loaded from your application instead of from the module provided by Glassfish.
You might also be interested in the issue GLASSFISH-15648 which aims to provide a dedicated Glassfish update package for HV.
As my case was ear, rather than war, based on suggestion of Gunnar, I did a patched version of the module, that is deployable to Glassfish (My version is 3.1.1 OSE).
Someone might find it still useful, see my blog for my solution (including step-by-step approach): http://peter-butkovic.blogspot.de/2012/11/glassfish-311-oss-with-hibernate.html