We Keep Coding

How can i make jenkins test for CDI runtime failures?

introduction
For a (school) project I'm working on we have to develop a medium sized java app that in our case uses javaFX and java CDI dependency injection, we have a scripted jenkins pipeline based on a groovy file that checks every pull request so branches that don't meet quality requirements or fail building can't be merged.
problem
Now we have the issue that only 25% of the developers currently actually run the application to test if their additions work, since the project is in so early stages that a lot of functionality we are currently working on does not get used by the GUI yet. The other 75% of developers use JUnit unit- and intergration-tests to check if their code works. While we could try to say everyone needs to run the actual application before making a pull request to check if there are no runtime errors with java CDI dependency injection. People are people and don't always listen so we quite often get code into develop that succeeds with maven but cant be run due to dependency injection issues.
question
What is the easiest way to check in the jenkins build that there are no issues with java CDI dependency injection that are going to pop up runtime?
sidenote
We already use JUnit but not all tests currently use weld injection for test, if its possible to make a single tests that checks all dependency injection issues that would also work instead of a jenkins based solution.

Your CI(continuous integration) approach is good. Testing all PRs is a way to go, you just need to decide what kind of test should be executed. JUnit style, or integration tests? Maybe both?
CDI itself has a deployment validation phase at which it checks, at bootstrap, if things are alright - if beans are passivation capable (those that should), if all declared injection points can be satisfied and so on. This can catch many user-errors before hitting runtime, so just deploying the app shows it. You can, and should, use Arquillian to set up a testing environment much like the actual runtime environment. Note that this validation (no validation in fact) cannot check dynamic resolution errors. E.g. when you use Instance<Object> and then try to resolve a bean that doesn't exist without checking.
If this isn't what you wanted, then you can consider weld-junit extension. This leverages junit (4 or 5) to bootstrap Weld SE container in which you can play around with your beans and test them. Look into READMEs and tests in the projects for examples. This doesn't reflect pure EE environment but is more of a junit style testing with CDI in it and easy to get started with.
Note that with Jenkins, you can setup multiple tasks for each PR. You can make it run all the JUnit tests as well as all the integration (Arquillian) tests for instance.

Testing EJBs with transactions without deploying it into a container?

My Java EE application contains EJBs which handles intermodular transactions. I need to test all these EJBs using Unit Tests. I can test the functions without intermodular dependencies. Is there a way to test EJBs without deploying it into any container?

We are having a look at arquillian. It seems to be the most common solution.

Well, another option is to use some sort of embedded EJB-Container like OpenEJB or Glassfish.
Nonetheless i would prefer the arquillian approach too.
Testing intermodular ejb-interactions looks more like some sort of integration test to me.
Therefore i would rather stick with a setup which resembles the runtime environment your EJBs will be deployed too instead of 'rebuilding' it with an embedded EJB-Container.
You might want to have a look at:
Best current framework for unit testing EJB3 / JPA
too.

Using a shared parent application context in a multi-war Spring application

I want to shared common application context in a multi-war Spring application, so i don't need to defined beans again and again. But i don't want to instantiate those beans defined in this common application context in each webapp. I only want to instantiate those beans once and share by all the webapps. Is it possible? Bare me if i'm wrong.
PS: this common application context exists in jar, which i'll import to every webapps.
1, Below article tell us how to share the common application context, but need to instantiate those beans in each webapp.
How to import spring-config.xml of one project into spring-config.xml of another project?
2, Below is another article i just read, i demo it, but still don't get what i want, beans got instantiated twice. Can someone check this section "Why would you want to use this?" in the article, i don't get it, do they have a solution there, can someone help me here, thanks a lot for your time.
http://spring.io/blog/2007/06/11/using-a-shared-parent-application-context-in-a-multi-war-spring-application/
here is the demo source code in second article: https://github.com/jasonluo/ceciic/tree/master/Research/multiple-contexts-sample
Updates
The problem of case2 is because i didn't deploy as a ear file, thanks Deinum for pointing this out, i'm using tomcat, so there is no way to achieve that.
Our solution now is using REST to access the service webapp which running in a separate server.

Don't, there is usually classloader isolation going on to prevent this. Doing this right usually requires a thorough understanding of classloading, Java EE, packaging and your server.
Having that said there is way to do this as outlined in the blog you posted. You have to:
package both WARs into an EAR (this means you have to use and appserver like WildFly AS and can't just use a servlet engine like Tomcat or Jetty)
package both WARs as "skinny" WARs with at least Spring (and all its dependencies) and the shared beans (and all their dependencies) in the lib/ folder of the EAR instead of the WEB-INF/lib folder of the WARs.
Even then it depends on implementation details of the server. AFAIK it is not guaranteed to work under the Java EE specification. For example it likely won't work in GlassFish.
Update
I can't tell if the output of your demo is correct because I couldn't find a build file.
Yes, Tomcat does not support EARs, you could use Apache TomEE which is very similar and supports EARs (I don't know if TomEE does classloading in a way that makes this work). In theory you could also make use of the common classloader in Tomcat but that would be quite a hack.

There is a way to do it, using Spring Dynamic Modules, but it requires OSGi environment, which is quite different from simple Tomcat. Few articles worth reading:
Deploying Spring MVC applications to OSGi
Hello world style example
Blueprint - a further development on DM
Another blueprint documentation reference to Spring
That being said there is not a lot of up to date information about Spring with OSGi, but it's worth a try to achieve just what you said (but of course, with additional performance cost)

Run Java Spring application from eclipse

I'm working on a project at work that runs on the spring framework and requires a connection to an oracle database at all times. When I want to test a new method I have to stop my server, rebuild, start the server, then launch my application.
My question is is there any way to run my application without having to launch it every time? I'm okay with having to restart the server but I'm trying to eliminate launching the application every time.
Cheers.

What you seek are integration tests. You need to break your application into individual pieces and test their functionality against the oracle database bit by bit. These little pieces can be tested by certain testing technologies such as the popular JUnit.
All the pieces that you need should only depend on the data source and whatever other collaborating beans that are needed. Break your bean definitions apart such that they are small and only depend on very few beans, tracking back to the data source bean. You can then use JUnit (or whatever testing technology you'd like) and Spring's testing annotations to make small application contexts
See this section of the Spring reference manual for more information:
http://static.springsource.org/spring/docs/current/spring-framework-reference/html/testing.html
When you have tests, you don't actually run the application - you run a part of it to verify its behavior individually. You can then add tests that test the pieces together, and eventually your confidence in the application will rise.

Where can I find JSFUnit real-life example?

I'm trying to use JSFUnit framework, but can't understand how to allocate projects/files. How many projects/sub-projects should I have and whether it is possible to have just ONE project, as it normally happens with JUnit and similar frameworks. Would be nice to see some example.
I still can't understand whether I need to create a separate maven project for testing purposes (as this page says) or I can work in my main project...

I'm trying to use JSFUnit framework, but can't understand how to allocate projects/files. How many projects/sub-projects should I have and whether it is possible to have just ONE project, as it normally happens with JUnit and similar frameworks. Would be nice to see some example.
The JSFUnit project itself has many examples (as we can see in the JBoss repository) and I suggest to get them from the subversion repository (checkout the whole jboss-jsfunit-examples).
I still can't understand whether I need to create a separate maven project for testing purposes (as this page says) or I can work in my main project...
JSFUnit tests are in-container tests and need to be packaged and deployed as a war. But you obviously don't want them to end up in the "production" WAR and putting them in a separate project is the obvious way to separate things (they will be then merged with the war under test using overlays). So, yes, create a separate project.
See also
Test, Test, JSF (the JSFUnit blog)
Intro to Exadel RichFaces and JBoss JSFUnit [PDF]
Testing RichFaces Applications with JBoss JSFUnit [PDF]