I have a dependency which contains both CDI and EBJ beans/classes, however in my Quarkus project I only use/inject the classes with CDI annotations. When specifying that dependency in my pom.xml and running Quarkus in dev-mode, I get numerous exceptions for classes that I don't use/inject in my project:
Unsatisfied dependency for type <unused CDI class using/injecting EBJ bean>...
I thought this was odd, since I thought that Quarkus only includes "used classes" into the packed jar.
Then I realized that maybe the problem stem from "javax.ws.rs" annotations in the classes of the dependency.
Does Quarkus scan all dependencies for classes with JAX-RS annotations and includes those?
If yes, is there a way to define which classes or packages should be scanned for JAX-RS annotations?
If no, is there another way to exclude/ignore certain classes from a dependency? An option to generally exclude or ignore classes from dependencies would be very helpful for similar issues too (e.g. ambiguous dependency, etc).
Thanks!
Related
I'm trying to convert a multi-module Maven project from vanilla Java EE 8 to Quarkus, and it seems that ArcAnnotationProcessor throws exceptions about unsatisfied dependencies for all injection points referencing dependencies located in a different module.
Is there any workaround, short of merging the modules?
Answering my own question:
According to the Quarkus CDI guide,
The bean archive is synthesized from:
the application,
application dependencies that contain a beans.xml descriptor or a generated Jandex index (META-INF/jandex.idx),
and Quarkus integration code.
After adding a beans.xml to each of my reactor modules, ArC no longer complains about missing dependencies.
I have an issue concerning a jar declaring CDI annotated beans, and used both in a spring context and an EE6 context.
This jar, say service.jar, contains classes that are annotated with qualifiers (#Qualifier, allows you to declare your own annotations such as #DataAccessObject in order to identify your beans), and has private members annotated with #Inject.
It's compiled with maven, and it's dependency to javax.javaee-api is declared as provided, because these classes are only needed when deployed within an EE6 context.
Though, there's something that I don't understand. In this service.jar, once compiled, and whether I deploy it in an EE6 context or not, the bytecode references classes such as javax.inject.#Inject.
So why my spring application - which has no javax.javaee-api jar in its classpath - is able to load its configuration correctly and run ?
I was even more confused when I learned that spring provides support for #Inject (JSR 330) annotation.
Can anyone enlighten me on that ?
Thanks.
You must not confuse DI (JSR330) and CDI (JSR299). CDI includes DI. All those javax.inject Annotations belong to DI and are supported by many frameworks (spring and guice for example).
If you strictly reduce your jar dependencies to JSR330 (no need to switch Java EE deps for deployment), you will be able to use any of the supporting frameworks.
Checkout this example: http://www.mkyong.com/spring3/spring-3-and-jsr-330-inject-and-named-example/
Hello I am new to the Spring and maven world, and I want to know what is the difference between this 2 dependencies?
Its a simple question.. I am having trouble with my pom.xml file, so I want to know everything :).
Thanks in advance.
These are actually 2 of many Spring Framework modules. You can easily find what packages these artifacts contain, using this site:
http://mvnrepository.com/artifact/org.springframework/spring-core/3.1.1.RELEASE
This can give you information about classes contained within a particular artifact and probably about the its purpose.
For Spring Framework, spring-core contains mainly core utilities and common stuff (like enums) and because it's really critical for Spring, probably all other Spring modules depend on it (directly or transitively).
In turn spring-context provides Application Context, that is Spring's Dependency Injection Container and it is probably always defined in POMs of artifacts that use Spring Framework somehow. In fact, spring-context depends on spring-core so by defining spring-context as your dependency, you have spring-core in your classpath as well.
Is it possible to configure Jersey via XML rather than annotations? Here's my issue:
I have a maven multi-module project with the following modules:
client
webservice
shared
In the shared module, I would like to put my basic POJO classes, with minimal dependencies in the Maven POM. The webservice module will require the POJOs to be configured for both Hibernate and Jersey (such as with #XmlRoot and #Entity annotations). The client module has no need for the Hibernate- and Jersey-specific configuration, and having the classes annotated would introduce the dependencies into the client POM.
Normally I actually prefer annotations over XML, but in this particular case I'm trying to keep the design modular and at least somewhat clean.
Any suggestions?
You can annotate the classes and mark hibernate and jersey as optional dependencies. Then the classes are annotated appropriately and your client is free from the extra dependencies.
I'm using Spring 3 and Maven. I've defined all spring modules in my pom.xml.
When I use <aop:scoped-proxy />, I get an error saying that CGLIB is missing.
Well... I add CGLIB as a dependency in my pom and it all runs...
I'm a little confused... Maven is a dependency manager... Why it does not download CGLIB when I use the spring-aop module?
It's not the only case... Why do some projects need explicit dependency declaration instead of using Maven transitive dependency mechanism?
It's because cglib is marked as an optional dependency.
Essentially you don't need cglib for every usage of the spring-aop library, so maven doesn't download it automatically. You need to specify it manually, unfortunately.
I'm a little confused... Maven is a dependency manager... Why it does not download the cglib when I use the spring-aop module ?
Because not everybody uses CGLIB (an AOP proxy in Spring can be a JDK dynamic proxy or a CGLIB proxy) so CGLIB is marked as an optional dependency in the pom of spring-aop and you have to add it explicitly if you want to use it. This is exactly what optional dependencies are for.
Another similar example is Hibernate that lets you choose between cglib and javassist in hibernate-core in the same way. Hibernate also lets you choose between various connection pools (if you decide to use one of them) or cache providers (only ehcache, the default, is not declared as optional).
My guess would be that cglib is not enabled in Spring by default. And therefore it's not included in the pom unless you explicitly enable it.
As far as I know, Maven cannot go into your Spring configuration files and determine if it needs additional optionally enabled libraries. Although, that certainly sounds like it would be a cool Spring-Maven plugin if it were possible to modify the pom on the fly via plugin. Not sure if it is, but it would be cool.
Good news - this is a problem of the past:
As of Spring 3.2, it is no longer necessary to add CGLIB to your
project classpath, as CGLIB classes are repackaged under
org.springframework and included directly in the spring-core JAR. This
means that CGLIB-based proxy support just works in the same way that
JDK dynamic proxies always have.
Read more here.