I noticed that there are only a few camel extensions available to use in native mode. I am wondering if it's still possible to use the other camel components if you don't compile to native? And if, is it usefull to go that way, or should we for example stick to spring boot?
Note that all Camel extensions might not need a Quarkus one. Basically, a Quarkus extension is needed if we need to tune the Camel extension for GraalVM (add reflection declarations for instance). The interesting thing is that you can even do the work manually to make your Camel extension work in GraalVM mode and then report back so that we create a proper extension for all future use.
In JVM mode, all Camel extensions should work flawlessly. If you encounter an issue, please open a GitHub issue and we will take a look at it.
About if using Quarkus in JVM mode is worth it, I'm obviously partial but I think the Quarkus approach is beneficial even in JVM mode. You still have some of the benefits of better boot time and reduced memory usage. Obviously, depending on your application, they might not be important to you.
Related
My project has requirement to deploy a Java Based application as an operating system Job (and not use any container). The application need to have following capabilities:-
Scheduling
Few HTTPS based services
Ability to make JMX calls
Storage: Data for last 5 to 10 minutes of transactions (not more than 600 rows X 20 columns). Something like embedded H2 or in-memory options
Decision Tree: Something like Drools..
My manager wants to write this application as a core Java with OSGized Jetty version. I am suggesting to use Spring Boot with embedded Jetty(which will give me ready to use capabilities for Scheduling, JMX Integration and REST Services).
His bend towards core Java is emerging from the requirement that this application needs to be extremely efficient, fast and self-contained. He wants to reduce dependency on any open source. I have never worked directly on OSGI but have used products coming out of it - like eclipse.
Can somebody guide how OSGI based development might benefit over SpringBoot?
For many people, OSGi is superfluous, because they don't see the value in being modular. Not being worth the trouble.
Think about the application lifecycle, more or less being plan-develop-test-deploy.
How many developers you have? If many, OSGi helps a lot, because being modular make the boundaries very clear. You can delegate things very easily.
If outsourcing is your thing, you can just handle the module APIs and tell them to develop against it. They will never know how the rest was implemented, no fear of secrets being leaked.
Unit tests are so easy. You obviously see what you can test, every else you mock/stub/spy/fake. Unit tests can be can be reused in Integration tests, of course that isn't news, but the trick is running Unit tests outside the OSGi container, and Integration tests inside. So if you decide OSGi was not worth it, your code stills works fine (unit tests being the proof).
You can make your app a collection of modules, and every module having independent versioning and source repositories. Makes easier to handle and find bugs. For example, the current app crashed, you find out that sub-module-1.2 is throwing errors, try with version sub-module-1.1(still bad), then version 1.0(good), bug was introduced in 1.1 (avoids bisecting the source code). Programmers don't need to be perfectly synchronized with each other if they are working in different modules.
How do you plan to update the app? Most frameworks are of the all-or-nothing approach, where you have to stop the world, update, then restart the app. If you make things modular, you just need to update that thing. Making the downtime very small, and sometimes even zero.
If you need to make a big change in your app, but can't afford to refactor everything right now. With OSGi you can run the system with both my-module-1.0 and my-module-2.0. You can even adapt my-module-1.0 to redirect calls to my-module-2.0, but that is a kind of last resort hack (just saying that you can, if you want to).
I can do everything you say without OSGi, right? Well, probably you can, but in the end, would be something like OSGi.
I love the Dependency Injection of my framework. No problem, OSGi have something like that.
I hate Dependency Injection, it kills my app perfomance. No problem, you can use something like osgi.getService(MyService.class);. The OSGi container isn't concerned about intercepting every call of your app.
OSGi is like Java++, Java plus modules.
You can mix Spring Boot with OSGi, can't say if this is good or bad. There are many libraries and frameworks that fit your list, many will work out-of-the-box with OSGi.
not sure if this is possible but was wondering if its possible to embed GWAN in spring boot app (like tomcat/jetty etc.) are. and how so?
As far as the Spring Boot documentation tells, the requirements are to package your G-WAN application as a jar (zip) file, and install and configure Spring plugins to connect the dots.
One of them, Gradle, takes 50.5 MB to let you use several programming languages: "Gradle makes the impossible possible, the possible easy and the easy elegant."
G-WAN delivers even more language mix in 200 KB of code. G-WAN works without configuration files, nor it needs any war archives to be built, and deployed each time you edit the code of a Java G-WAN script. G-WAN's philosophy is real-time "edit & play".
With some adjustments, it will be possible to use G-WAN with in a Spring Boot application, but thats' like trying to attach a lorry trailer to a formula one: are the expected gains worth the exercise?
If you see advantages at adding this much code, configuration and maintenance overhead to G-WAN, could you please try to enumerate them?
If you are an advanced Spring developer and you still believe that there's value in this proposition, we will help you by adapting G-WAN wherever needed, providing you or other Spring experts can tell what must be done.
We are working on a new project using Spring, Hibernate and Transaction management using AspectJ (#Transactional annotations) and we are not sure what is the best practices weaving options to go.
We've started with the LTW and placed the tomcat Loader, it worked fine.. but then we thought that it may be less risky to have compile time weaving which instruments and *.classes and not on load time (in memory), so it will done just one time and not when on the tomcat startup. This is done via Maven aspectj-maven-plugin plugin.
Can you please advice ?
What are the pros and cons of using those weaving options ?
Thanks!
Disclaimer: This is not a discussion forum but a Q/A platform, so your question does not have the correct answer, it rather sparks discussion. I am trying to elaborate a bit anyway.
You basically already stated the main facts about LTW versus CTW. I am failing to see why LTW should be more risky than CTW, though. It slows down your server start-up, but the risk is the same as with CTW because the resulting byte code is also the same. Or are you talking about the risk that maybe more code gets (e.g. 3rd party libraries) woven than you intend? In that case yet, CTW keeps you on the safe side and you have more control over what should be woven. It should also speed up your server start-up time in comparison with LTW.
So if you have no compelling reasons to use LTW, such as the wish to dynamically intercept code you are unaware of during development, go ahead and use CTW and you are on the safe side, as long as you are fine with adjusting your build process accordingly. AspectJ Maven plugin is pretty straightforward to use, so that should not be a big deal. You can still switch to LTW as needed and when needed. OTOH, if you are using LTW now and are fine with the server start-up time, maybe there is no need to switch. If unsure, try both approaches and compare the results. ;-)
Our application is having issue with rendering time on various part. We have been able to pin point the performance issue with a profiler (YourKit Java Profiler) within the JSF restoreView phase (lifecycle). Since, we use a lot of components in some pages the rendering of the tree must be the source of the problem. Some question on stackoverflow looks pretty much like what we are dealing. Also, we can see the same slow speed in dev and production.
Some specs:
MyFaces 2.1.7
javax.el 2.1.0
Profiler (CTRL+SCROLL to see details):
We are trying to find solutions. So far, we came up with those:
Use less composition/components (which is not that great, because we liked to make generic component).
We could also go into JSF stateless mode.
Find the actual problem with JSF (IN DEEP).
Recently, we found out that some JUEL library (expression language) could greatly increase the rendering time.
I've been dealing with making JUEL works with Spring 3 (with OSGI). Here's the spec:
JUEL 2.1.3.1 bundle (note: this bundle use a different version of javax.el than the one I use in my application will that cause clash?)
I have found another maven repo which only does Juel Implementation and a more recent version.
Update:
Found a solution for javax.el clashing, since there was a lot of problems in the juel-api (because it's export his own javax.el) I modified the manifest with that line Fragment-Host: javax.el to eliminate it.
Is there a configuration/set up to enable better performance?
Or, how to you actually configure JUEL with MyFaces and Spring?
I would say that the problem is caused by Spring Web Flow. I remember this issue SWF-1540. First check if you are using the right version (2.4.0.M1 or upper). Note personally I have not tested if that configuration has a performance issue, but I can say that MyFaces 2.1.7 an upper versions does not have any issues. It is known that some EL versions has perf issues, so try with juel or with apache EL (jasper-el, bundled with Tomcat).
As a personal opinion, watch out for Spring proxies, it is known that in some cases, when the pages are very big and complex, the proxies has a significant impact over performance. The suggested solution is use Apache OpenWebbeans, which is a very fast CDI implementation, optimized for those cases when you have a lot of beans interconnected.
You can check this article too "Understanding JSF 2 and Wicket: Performance Comparison" for tips about MyFaces performance.
You have to try by yourself what will work for your case, but I hope with these advices you can focus better your search.
The current system I am working on uses Tomcat 7.0 and Spring 3.1 the system is a collection of web apps that all have the same classpath in WEB-INF\lib, I am thinking of adding spring 3.1 to my tomcat\lib so that all the web apps have access to it. Is this safe to do with Spring 3.1?
Safe to add Spring 3.1 to the Tomcat main lib directory? Quite possibly. Good idea? Probably not; as the system administrator you'd be taking on the responsibility for ensuring that all the webapps can use that exact version of Spring (including all the issues that can crop up when you update things) because the webapps would not be able to override it to anything else. (To be fair, they could load classes from elsewhere that weren't in the standard system version you're proposing, but that's likely to be an extremely bad idea as there would be problems with warring versions of the same library. That's a very confusing situation to be in; avoid if at all possible!)
As a general rule I only put very basic shared libraries like JDBC drivers in tomcat/lib. Sharing other libraries will often lead to classloader issues in tomcat. Unfortunately, I don't know the publish date of it, but you might find this article http://www.mulesoft.com/tomcat-classpath useful.