I want to build a REST API using RestEasy. The generated file should be deployed in a WildFly application server.
I face the issue described in the following SO-question:
AsynchronousDispatcher error
The marked solution tells me, to set the dependency to "provided". Which as far as I understand means, that the library is not included in my war file but taken directly from the app-server...
Isn't that just wrong?
My idea would be to build a self-containing war file which contains all the needed libraries in the version I need.
When provided from the app-server I do get the currently available version from there. I have not really a clue about the version... when someone has the idea to update the RestEasy library on the server, it might break my app.
I'm not sure whether I missed something or did something completely wrong?
One of the big advantages to Java EE is developing towards the API and not having to worry about the implementation. Java EE containers provide the API's and implementations for the API's. If you include implementation dependencies one of two things is likely to happen.
You're dependencies will be ignored making it pointless to include them in your deployment.
You'll get conflicts between the dependencies you included vs what the server is expecting. This could be things like:
ClassCastException because it's finding two of the same class on the class path.
MethodNotFoundException because there is a version mismatch
Various other issues with conflcts
Developing towards the API instead of the implementation also allows you to easily switch between Java EE compliant containers with no to minimal changes to your deployment. The API's are generally backwards compatible as well making version upgrades not as big of an issue.
If you want to use a fat WAR (including implementations) instead of a skinny WAR (not including the implementations) then a servlet container is probably a better solution. WildFly does have a servlet only download. I'd encourage you though to trust container to do the right thing with the implementation dependencies :). Usually the only time there is an issue with upgrading is if you're upgrading Java EE versions. Even then it's usually pretty safe.
Related
I am facing this unique problem, i have some custom libraries deployed in weblogic lib folder and some of them have same package structure and even some classes have same names. But these libraries are being used in different applications, so applications dont give any compile time error. But in a shared environment, they are causing trouble. Any suggestion on how to fix this with minimum changes. I am using weblogic 11 server and working with EJB 3.0 applications.
The problem is at level of design. A good library or application should have a custom package not reused by other libraries or applications.
The best solution is to refactoring your code changing the package names. Don't limit the changes to the conflicting classes, but change the whole package. It should be simple with modern ide (Eclipse, IntelliJ).
For next projects remember to use always a syntax for packages like the following
com.yourcompany.yourproject.specificpackages
this will guarantee that no class will go in conflict with others.
I had first found a reference to JBoss Modules when I stumbled upon Ceylon language which uses JBoss Modules as its module system. Immediately I wanted to try this system in some toy project and maybe even embed it in a real project (I was writing a project with plugins support at that time), but I couldn't find any documentation on JBoss Modules as a standalone library. The only available documentation source seems to be the official wiki, but it looks abandoned and unsupported. I couldn't even find Javadocs for it (except, maybe, this, but it seems to be very old and not really related to JBoss Modules due to "osgi" presence in the link).
It seems that JBoss Modules are usable outside of JBoss AS because Ceylon language uses it, but lack of almost any documentation on the subject is disappointing.
So, here are my questions:
Is it possible to use JBoss Modules as a standalone library at all? Are there any artifacts in some public Maven repository?
If it is (and there are), is there any documentation on it? That wiki I have mentioned does not have, for example, any instructions on embedding JBoss Modules.
If you'd like to try out JBoss Modules directly, you can grab the dependencies from the JBoss Nexus repository: https://repository.jboss.org/nexus/content/repositories/public/org/jboss/modules/jboss-modules/
Unfortunately, there isn't much documentation on JBoss Modules, but if you want to try it out, you probably don't want to be hand-writing modules.xml files yourself (maybe you like pain, I don't know.)
If you'd like to try out "Furnace" the modular container based on JBoss Modules and Maven that serves as the core module system for JBoss Forge, it give you the ability to write Maven projects that can be loaded directly as Modules. This is what we are using for our entire Forge 2 architecture.
You can find some docs on Furnace here:
https://github.com/forge/furnace#furnace
https://github.com/forge/core#developing-an-addon
Note that Furnace Addons require a maven classifier, you can choose the classifier used if you want to. This is done via the Furnace Manager (which can be seen in the furnace docs above.)
Yes. Actually, JBoss is using it that way as well - so JBoss application server is actually running inside JBoss Modules system.
I'm not aware of such documentation, but usually you shouldn't be embedding jboss modules, but running the applications with it. I'm not aware if you can embed it.
I actually got most information from this presentation in vimeo, Modular Class Loading with JBoss Modules. There seems to also be Zen of Modules video there.
I'm a student with quite some experience in Java but totally new to Maven.
I was trying to implement a RESTful service provider and client with jersey-server and jersey-client. Both also depends on jersey-json, to make use of automatic conversion between POJO and JSON. Both of them also depend on a service model I implemented myself, where the POJO definition resides.
However, the code doesn't work for me. I spent quite a few hours looking for solutions everywhere on the Internet. It turns out the reason of the failure is that I accidentally specified version of jersey-server and jersey-client as 1.14, but jersey-json as 1.9.1.
The server doesn't work at the beginning, but at some point suddenly starts working. (I have no idea how this happened.) The client never worked until I change jersey-json version to 1.14.
Why do I need to have the same version for these different dependencies?
Because one depends on the other or otherwise has a compatibility issue. This is what dependency management is all about. Run mvn dependency:tree to see exactly how these libraries relate to each other.
In this case, it seems Jersey libraries are all released together as a "bundle" - and you need to use the versions from those bundles together. See: http://jersey.java.net/nonav/documentation/latest/chapter_deps.html
Note that this is an attribute of the Jersey libraries, not Maven.
Often different jars from the same distribution are tested together and given the same version number.
If you try to mix different versions it might work, or it might not, as its not a combination which was intended or tested.
I'm a long time ASP.NET developer trying to teach myself java. I've got Jetty downloaded and a basic web app setup. The tutorials in Head First Servlets and JSP tell me to reference the container's servlet-api.jar (or servlet-api-3.0.jar in Jetty's case) file when compiling, which makes sense since I'm extending the servlet classes and all, but doesn't this tie my application to a specific container's servlet implementation? If I compile my app against Jetty, can I still deploy the app under Tomcat or any of the EE servers (glassfish, jboss, etc...)?
No, this shouldn't be a problem because you aren't referencing servlet-specific classes. servlet-api.jar is a well-documented specification in the form of several interfaces and abstract classes.
Every container has to have a copy of this JAR (possibly compiled using different Java version, or compiler) because it implements the specification, but the API itself never changes. However note that you don't really have to reference container-provided JARs. You can safely use maven's version or any other you can find. They are all compatible. Sometimes they are not bundled due to various licensing incompatibilities.
That being said: write once, run everywhere applies here as well.
You aren't coding to the jar, you are coding to a specification which the jar happens to contain. Any server providing a web container will have an implementation of this specification, the jar which it is contained in is totally irrelevant.
As long as you only code to the specification, then you are not bound to any server implementation.
The jars are used at compile and runtime to resolve the necessary class dependencies you have. You can use any jar which provides the necessary API dependencies at compile time, but at runtime you will implicitly be using the implementation provided by the specific server. I say implicitly since you do not have to do any specific configuration for your own webapp to include the standard API or it's implementation, the server will already provide that for you, unlike a standalone app.
i have an API that is being written for a large group of 40 or so applications to share.
my problem is currently they plan on having the API as a simple library included in each war file for each program. the problem thats going to occur is when two apps are running on the same instance with different versions of the api library. ive had a lot of problems in the past with this.
i seem to remember a while ago something where i can wrap my library into an ear file or something and deploy it to tomcat to make it global. simply including it in the lib folder won't work because it will include hibernate systems that have to be deployed to allow the api methods to access the database. then in each application i would have an interface i can implement that allows me to call those api methods. very similar to local EJB3 but not as complex and didn't require an enterprise level server to implement.
anyone else remember something like this or was it a bad dream on my part?
You will have problems if you use a single jar shared by all the webapps, since it will then be impossible for two apps to use a different version of a library. But if each webapp has its own version of the library in its WEB-INF/lib, the container shouldn't have any problem: each webapp has its own classloader, which doesn't see the libraries of other webapps.