What is the simplest way to convert EJB 2.0 (WebLogic 8.1) project to EJB 3.0 (OAS or WebLogic etc)?
I found just this article "Converting an EJB 2.0 Entity Bean to EJB 3.0", which could automate this process, but forced to do too much manual manipulations.
IMO, you can't really convert an EJB 2.1 project to an EJB 3.x project. You can however migrate and this is a project by itself. Some more resources:
Migrating EJB 2.1 Entity and Session Beans to EJB 3.0
Migrating EJB 2.x applications to EJB 3.0
Use Intellij's "Apply EJB 3.0 Style" tool. It automates a lot of the painful steps, especially replacing ejb-jar.xml configurations with annotations. Migration can be applied incrementally (you select the ejb's) or all at once. It does other steps for you as well; details here:
http://www.jetbrains.com/idea/webhelp/migrating-to-ejb-3-0.html
I found this to be immensely helpful and worth the price of an Intellij license all by itself for the number of hours it saved me. I did not find anything comparable in either Eclipse or Netbeans.
An old, but helpful, additional resource:
http://www.javaworld.com/javaworld/jw-08-2006/jw-0814-ejb.html?page=1
Related
I am getting a little confused by all the naming and versioning of .NET. I think I understand the whole .NET Framework / Standard / Core thing, but I am now moving into ASP.NET Core territory (I want to give my console application a web interface with Kestrel).
When using the NuGET package manager, I can see the Microsoft.AspNetCore.Hosting package, needed to run the webserver. But the highest available version is 2.2.7.
Question now, is that 2.2.7 part of ASP.NET Core 5.0, or do I have some configuration incorrect that I do not get the latest version for my application?
And if it is indeed part of ASP.NET Core 5.0, where can I find that reference? This table helped me a lot with understanding the core libraries.
I assume you wanna this document which tells about your package :
https://learn.microsoft.com/en-us/dotnet/api/microsoft.aspnetcore.hosting?view=aspnetcore-5.0
And I think you can focus on those classes or interfaces you'll use and take a look if those are supporting .net 5 by click and refer to the details page. You'll see Applies to at the bottom of each page such as this one.
If I misunderstood in some place which made my post isn't suitable to display here, pls point it out and I'll delete it.
I have a custom authentication component that is working with net core 2.2. I've started migrating the project to net core 3, but it seems like MS hasn't updated the authentication Nuget packages.
Until now, I was referencing the Microsoft.AspNetCore.Authentication package. The package still exists, but hasn't been updated to net core 3.0 (it's still on the 2.2 version).
I can't keep using it because net core 3.0 has moved the RequestPathBaseCookieBuilder type to a different namespace (so, at runtime, I'll get a tyoe loading exception). A quick search shows that only the Microsoft.AspNetCore.Authentication.OpenIdConnect has been updated to net core 3.0 (and if I add it to my project, then my component to work without any issues).
Anyone knows why MS hasn't still updated the other security nuget packages to version 3? Is there anyway to solve this without using the openidconnect nuget package (I'm only using it because it was the first that was updated and it will bring the correct Microsoft.AspNetCore.Authentication assembly that I need for my project)?
Looks like I was 10 minutes too late, but you posted the answer as a comment, rather than an answer, and I like questions having answers so I stop opening them when browsing the question search results.
Anyway, as you discovered, .NET Core 3.0 no longer uses packages for base class libraries (BCLs). Instead, they're just part of the SDK, so by targeting netcoreapp3.0 or netstandard2.1, all BCLs are just available. This should eliminate a lot of problems that earlier .NET Core projects had, particularly when referencing .NET Standard 1.x assemblies from netcoreapp2.x tfms. Although the largest benefit will be when all referenced packages target netstandard2.1 or netcoreapp3.0 or above.
Ok, so finally got it. The solution is to use the FrameworkReference element with the Microsoft.AspNetCore.App meta package.
For .NET applications, it is clearly documented how to do logging with Xray. The mentioned library is based on the .NET Framework and does not support .NET Core which became clear to me after installation (warning messages). There is an alternative that does not have a .NET Framework dependency. However, the xray documentation does not mention this library so hopefully someone can explain how to do logging with xray within a .NET Core application.
For a .NET core application add this line as soon as your app starts but after you configure log4net. If you're not using log4net then you can choose from a couple other logging options.
AWSXRayRecorder.RegisterLogger(Amazon.LoggingOptions.Log4Net);
You'll need to reference this assembly though. https://github.com/aws/aws-xray-sdk-dotnet
I have an EJB 2.1 project, works on WebShere 7. I must migrate it to WebSphere 8.
Which one is the better (less effort) approach:
First convert the project into an EJB3.1 project then migrate into Websphere. If yes, is it easy to do that by a large project?
Adapt the project till it works on Websphere8 (What should be taken into account)
Thanks??
The easiest approach is to do nothing: WebSphere Application Server v8 supports EJB 2.1 just as well as v7. Why risk changing something that isn't broken?
I want to upgrade to NHibernate 2.0 from NHibernate 1.1.
Am I obliged to upgrade Spring.NET to v1.2 as well since we're using the NHibernate/Spring.NET integration module? We're currently publishing our releases under .NET Framework 3.0.
I did this a few months ago and didn't have any major issues. I think I had to make a couple of changes to a few relevant calls, and use the NHibernate20 assembly. Give it a go, what harm is it going to do? As long as your code is in source control you should be able to revert back. And then you can run your tests ;-)
.NET Framework 3.0 or 3.5 is okay as well, as they both sit on top of .net 2.0: http://en.wikipedia.org/wiki/File:DotNet.svg
Good luck.