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.
Related
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!
I have a reusable component that right now uses Spring in order to be properly instantiated, that means that Spring will autowire all the dependencies that my component needs. I want to make this component a maven module and import it to other projects. All the projects that will use this library are using Spring as Dependency Injector. Can Spring still manage the dependencies for my maven module or do I need to do that manually.Are there any best practices for such scenarios? What I basically asking is how to tell spring to manage the dependencies of my library.
I have an application, that my JAXB2 annotated classes are possibly stored in multiple JARs, and I am using them in my web app (which use Spring MVC with Spring OXM Jaxb2Marshaller to expose RESTful WS).
I would want to generate the XSD for all classes that is possibly be used in my WS. However, com.sun.tools.jxc.maven2:maven-jaxb-schemagen-plugin and org.codehaus.mojo:jaxb2-maven-plugin are generating by inspecting the source code of the project but I want some similar solution which base on the runtime classes, as my POJOs are stored in other JARs, which APT will not be able to scan my code.
It is fine to generate the XSD in compile time, or by running the web app. Is there any solution?
Use JAXBContext.generateSchema(...) in the runtime.
See this answer:
Is it possible to generate a XSD from a JAXB-annotated class?
I am working on a webapp which uses Primefaces as a view, and I inject Spring beans from other projects into JSF Managed beans.
I have an architectural problem:
I've created separate projects(modules) for each component that I use (Business Logic, Persistence, and others) and also create separate projects with their interfaces.
I want my webApp to depend only on the interface of the Business Logic, and to inject the implementation of the BL using Spring Dependency Injection.
I want to achive this recursively: Business logic to depend only on other interfaces, and to inject implementations using spring.
The problem is that having no dependency in the Maven pom file to the actual implementations, when I deploy the application (on a web logic server) the implementation jars are not deployed, and Spring doesn't find the beans to wire.
Is there a way to achieve decoupling without adding dependencies to actual implementations?
Can I include Spring's bean configuration files from other projects if the projects are not added as dependencies?
Did I figured this decoupling all wrong?
I appreciate your ideas.
Well obviously you need the dependencies in your maven pom else nothing will be included. You can add the dependencies with a scope of runtime which includes them in your final war but not during development (scope compile).
For loading the context of modules you might come-up with a naming convention and/or standard location for your files. With that you could do something like this in your web applications beans xml
<import resource="classpath*:/META-INF/spring/*-context.xml" />
This would load all files ending with -context.xml from the /META-INF/spring directory on the classpath (including jar files).
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/