We have several inhouse built plugins which we use in our spring boot based microservices. I want to upgrade those plugins to use java 11 and higher gradle version but some of our services are still using java8 and lower gradle version.
I want to see if anyone has experience with this and have any recommendation. Can the plugins be updated without any side effect or the service utilizing the plugin or should they be upgraded as well
Tried to upgrade the plugin without upgrading the service which is utilizing it. I am not seeing any issues with testing yet but want to do more research before releasing the service.
Related
we have microservices with 4.9.0 and with 5.2.1 and now we want create new microservices with 6.x.x is recommended have microservices with differents versions in the same registry?
We dont upgrade because we tried and is impossible we have a lot of code yet in old microservices.
And in gateway is imposible migrate angular 4 to angular 6 with our quantity of code.
I have successfully used a recent registry with gateways and services generated by JHipster 3.9.0. Eureka REST API is quite stable. I have upgraded manually some services from Spring Boot 1.3 to 1.5 in order to be able to use hazelcast-eureka-one that required a more recent version of Spring Cloud.
I don't understand why you say it's impossible, unless you want to use jhipster upgrade or you don't have a good test coverage.
I don't plan to use jhipster upgrade at all, it would be a waste of time because of too many major versions until current. I prefer to copy my .yo-rc.json and JDL to a blank folder and generate with latest version of JHipster and then pick up what I need, step by step.
Upgrading from Angular 4 to 6 is easy, it should not be a problem for your team.
Overall, I don't see it as a JHipster problem, it's the same as if we had started from scratch without a generator.
We have a huge project with a lot of obsolete code and dependencies including spring-core, hibernate, spring-security and a lot more.
Having in mind that we have to migrate this project on JDK 11.
Our first attempt was just to build project with JDK 11. In some cases it worked, but when integration tests were to run, spring(ASM) confused with bytecode. Having read answers on this topic i saw that starting from spring 5 Java 11 is supported. So updating to newest frameworks would be great decision but.. A huge amount of work needs to be done, so much that we cannot even estimate it. My answer is: Have anyone tried running spring 3 on new java versions (8 works fine) or is there an opportunity to do that. Maybe some kind of dependency replacement - to use newer ASM etc or to fork spring and make some changes there? What do you think?
I am working on building a workflow application and I'm planning to use JBPM as my BPM framework. Can anyone suggest me which is the stable version to use in producation environment?
You can try with enterprise release of jBPM which is Red Hat JBoss BPMS. Red Hat will provide hot-fix patches to known issues. Also rollup patches are provided on certain interval, which includes fix for multiple issues. Along with all this you will get 24x7 support for issue.
Just let you know, I have been using jbpm 6.5 with docker in production for 2 months. All work smoothly
As the title says, I want know if it is possible to run an application coded in Eclipse RCP 3.X above an Eclipse 4.X target platform without making structural changes (such as migrating the application code to eclipse 4.X). If so, how can I do that?
Eclipse 4 still supports Eclipse 3.x RCPs using a compatibility layer.
As long as you have not used any internal interfaces you should not have much trouble upgrading.
I've recently begun working with a large, legacy enterprise Java application. It's primarily built on Websphere Commerce 6. It contains a mix of EJB 1.x and 2.x along with quite a bit of code that hooks directly into the Commerce API.
I've introduced the first unit tests while attempting to break dependancies and carefully refactor small portions of the code. We've been exploring the idea of using an integration testing framework to make the process of creating tests less fragile and time consuming.
Arquillian has been suggested as a very good option for integration testing. However, it looks geared towards more "modern" applications; most of the examples make use of Java EE 5+ and Maven. We're using J2EE and Ant. We're also currently tied to Java 1.4, and while it may be possible for us to move to Java 5, we won't be upgrading to EJB 3.x any time soon. We're also likely to stick with Ant.
With these constraints in mind, is it possible to use Arquillian? Or do better alternatives exist for integration testing legacy enterprise Java applications?
Arquillian has been suggested as a very good option for integration testing. However, it looks geared towards more "modern" applications; most of the examples make use of Java EE 5+ and Maven. We're using J2EE and Ant. We're also currently tied to Java 1.4, and while it may be possible for us to move to Java 5, we won't be upgrading to EJB 3.x any time soon. We're also likely to stick with Ant.
With these constraints in mind, is it possible to use Arquillian?
Note: I'm an Arquillian contributor. I've tried to be unbiased in my answer.
This would really depend on how your tests are executed. If you are attempting to use Arquillian's support for in-container tests, then you're unlikely to find a solution. WebSphere Commerce 6 uses WebSphere 6.0 as the underlying container, which is not supported by Arquillian at the moment. If you can hypothetically use a version of WebSphere Commerce that uses WAS 7.0 or 8.0 as the foundation, then most of my answer can be ignored, since these containers are supported.
You can attempt to run tests from the client using the #RunAsClient annotation, instead of the container, and this is more likely to succeed. Note that, you'll need to perform the deployment in some manner without a #Deployment annotated method, because of the afore-mentioned absence of support for WAS 6 in Arquillian.
If you intend to use Ant instead of Maven, then the only requirement is that all dependencies be present in the classpath. Unfortunately, there is no uber JAR or distribution for Arquillian, so for now, you'll need to know all the dependencies upfront.
Note - Building in WebSphere 6.0 support for Arquillian may not be a trivial activity, as compared to other more recent containers:
Firstly, there have to be means for deploying the archive. I'm not sure if the mechanism used in WebSphere 7 and 8 container support can be ported over.
Supporting in-container tests in Arquillian for WAS 6.0 may require supporting the Servlet 2.4 protocol for running tests. Currently, Arquillian supports Servlet Spec 2.5 and 3.0 for packaging it's ServletTestRunner. This is of course, necessary if the JMX protocol and the accompanying JMXTestRunner cannot be used.
Or do better alternatives exist for integration testing legacy enterprise Java applications?
I would normally advise folks to use a mix of Cargo and JUnit for functional testing legacy apps, but even Cargo does not appear to support WebSphere 6.0.
You might find JUnitEE to be a better fit for your needs if you are willing to package the JUnitEE TestRunner in your archive; note that JUnitEE's last release was in 2004, and the mailing list is a bit inactive, so YMMV.