Everybody in the world, except me, seems to know what exactly the "Dynamic Web Module" facet is adding to a project. Web search reveals tons of responses how to recover from various errors originating in more or less unwanted changes in the version of this facet, but there is hardly any information about what the facet actually does.
So my questions are:
What exactly does the "Dynamic Web Module" facet add to my eclipse project?
Why should I want this to happen?
Why do my colleagues using IntelliJ, Visual Studio Code etc. –where this concept does not seem to exist– have no problem?
Keeping mind that I didn't decide on these names (and I grumbled about them myself at the time)... The term dates back to the early J2EE Tutorials, like https://docs.oracle.com/cd/E17802_01/j2ee/j2ee/1.4/docs/tutorial-update2/doc/WebApp3.html The tutorial would explain that J2EE web modules are the web applications from the then Java Servlet specification. J2EE loved to subsume the other specs and use its own naming for things that already had names. The doc and tools often followed suit.
It also mentions that they can contain static web resources, and in fact you can run web modules that only contain static resources. So WTP has the concept of a static web module and a dynamic web module, as static web projects and dynamic web projects in Eclipse. The Facet designates a project as being one of the two, and for dynamic modules, which API level it supports and requires at runtime.
Server adapters then have to state which API versions the server types they provide can support. The Server Tools and validation can then help you avoid deploying to an incompatible server, as well as build against a valid server. You want to build against a valid server in the same way you want to compile against your intended Java runtime. It's the most straightforward way to, for example, avoid calling classes and methods that didn't exist at the time.
There's also a Module Core nature that gets added, which supports APIs for describing the deployment details. Details like saying your Java class output folder contents go into WEB-INF/classes, that the jars you select go into WEB-INF/lib and that those static resources go into the application root, all to comply with the layout expected at runtime. That API is meant to be pluggable, so it can be fulfilled by e.g. Maven integration.
The terms in the UI can be changed, but that has its own pain points. The community tends not to update old videos and tutorials that have been correct for years.
Related
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 am currently compiling a list of third-party libraries used in a web application. The application is deployed in tomcat. I am wondering which of the third-party jars actually must or should be included in the distribution. In particular, I am currently wondering how to best use javax-libraries.
For instance, I would assume the javax.annotation-3.1.1.jar can be used in some standardized way, e.g., downloading it as an extension, without me including it into the distribution of my own piece of software. However, I have it included as a transitive dependency from jaxws-api which I need for web services and therefore it is included in the application's lib directory.
I understand I could use the Extension-List manifest entry to cause the target machine to download and install such jars. However, then they are visible for other applications on the same machine as well which may require other versions of the same libraries.
So, I have some questions about 3rd party libs and I would be very glad if someone could give me some hints:
What is the best practice to use third-party libraries?
Is there some best practice for the javax-libraries?
Can and should I avoid redistribution without imposing a large burden on the person installing the application?
I have to admit, I haven't understood the notion of "redistribution" here, maybe you're using some concrete application server terminology, so I'll try to provide a common answer here, assuming you have a war.
WAR (stands for Web Archive) should include all third-parties used by the application.
These reside in WEB-INF/lib folder.
Now, each Java EE server should "understand" javax libraries, because it contains the relevant interfaces. "javax" libraries usually provide interfaces and the implementation/code that works with these interfaces are provided by the application server developers.
For example for servlets technology, Tomcat (or name any web server) will contain HttpServlet abstract class inside its internal libs, it will scan your war and find where do you implement/extend it, this is how it recognizes your servlets actually.
Now, you shouldn't include servlet-api jar into your war, because its already exists in the application server.
If you're using build tools like maven, they allow to build your war so that some thirdparties will be used for compilation but won't be packed up into war.
I didn't understand why is it so difficult to install the application - in the easiest case - you throw the war into the web server and that's it.
Hope this helps
I have a large scale project I am working on at the moment using Eclipse. Normally, as a one man team, these problems would not be an issue, but as our team is not one person we need to be able to break up pieces of the project to be worked on by certain team members.
In simplicity, let's say I have two layers to be separated apart:
1. Each DAO is a separate Java project, to be worked upon individually
2. The web-tier service layer contains all of our service endpoints and must be able to reference all of the DAOs. This layer runs on Tomcat as a dynamic web project, and utilizes Adobe LiveCycle Data Services as the piece that handles creation and management of endpoints.
Now, the issue we are running into is that when we create a DAO and unit test it individually it runs great. But when we reference it into our service project and try to run it we begin to get all kinds of issues related to the fact that we have two different versions of certain jars referenced in and as such we begin to have errors when running the server.
As a result, we know we can solve the issue by pulling the problem jars and ensuring that this is not an issue again in the future, but as I said before this is a large scale project with multiple people working on it and we don't want to be spending our time weeding out dependency issues when under the gun.
We are looking for recommendations on where to proceed for alternative solutions? Our team is new to JavaEE and as such we don't have much of a bearing on what we can use to tie everything together in it, or if it is a viable solution. Should we be looking at turning our DAOs into EJBs and deploying them in an EAR library? If so, where would our service layer lie, and would the service layer be able to reference the DAO classes since the EJB maintains it's own classpath (from what we have read?) Are we looking down the wrong path, or are we completely wrong in our current understanding of JavaEE?
Any assistance is greatly appreciated. We are still in the framework stage of this project and we want to be sure that we will be able to maintain it in the long run.
I second the Maven recommendation. That can add all sorts of sanity to your project structure.
Maven can even generate Eclipse workspaces via mvn eclipse:eclipse
An important clarification on the EJBs note. As of ava EE 6 is you no longer need to separate EJBs from Servlets and can use them together in the very same jar in the war file.
So understand from that that using EJBs or not no longer has any impact on packaging or classloaders as it once did. These are now separate decisions. EARs and classloader separation should now be viewed as a feature you might want to use should you want classloader separation and the complexity it brings. Most applications simply do not need that and are more than fine with just a war file containing servlets, ejbs, jpa entities, cdi beans, jaxrs services and whatever else you need. You are free to decide how you want to separate them or if you want to bother separating them at all.
EJBs do make great DAOs due to transaction management, something you don't get from plain Tomcat but can be made available in Tomcat via TomEE and works fine in Eclipse. You should consider EJBs for that reason, not for dependency reasons.
Side note, as you're new to Java EE, you might find this helpful:
http://openejb.apache.org/examples-trunk/index.html
In order to have things organized when working with Java EE in teams of 1+ people I could suggest:
Use Maven to manage your build process and library dependencies.
Maven has a small learning curve, but once you grasp it you will be grateful. By using Maven you no longer depends on Eclipse to manage your classpath.
A thing about it that I think is really helpful when working in teams is the install feature. Suppose you are woking on the version 1.0 of an EJB module, say core-ejb-module-1.0, and you've got it to a stable state and want everyone working in the project to refer to it from now on.
You then run a maven command like this on it: mvn clean package install
Maven will clean this module, compile it, run tests, create the jar and then install it to a repository that you define. Could be any computer in your company.
Now you may tell the guys working on other projects to update this dependency version on their .pom file and in the next build they run, before compiling, maven will download this library and then use it. Really neat. No more classpath hell.
(There are other ways to always automatically refer to the latest library as stated in this post, but there are some caveats. Anyway it's just an example.)
Use JPA/EJB instead of DAO Pattern.
Some people say DAO meaning any sort of data access, others really mean that they use the DAO Pattern to access objects. If that is your case, you no longer need to use it when using JPA. (At least for most common scenarios).
In my case, I have a generic EntityService which is capable of doing CRUD operations on any Entity and has a centralized query management. Then every EJB's that should perform database related operations may inject this guy and do its job.
As a suggestion, with Maven, you project could be organized as such:
core project structure
core (The pom root)
core-ejb-module (Includes all generic EJB's, like the EntityService for instance.)
core-jpa-module (Includes all JPA generic definitions, like Interfaces, MappedSuperclasses and such.)
core-jsf-module (Includes all JSF generic definitions, like abstract controllers, generic converters and wrappers for FacesContext, etc..)
Now that you have a core generic module setup, you could create:
an application structure
app (The pom root)
app-ear-module (Includes all other modules in this application. Shared jars goes in the ear /lib folder, so all other modules could reference to them.)
app-ejb-module-a (Includes EJB's for the business layer of your application. It uses the core-ejb-module)
app-ejb-module-b (You may have lots of ejb modules. You may even have a project that contains only ejb modules. Other apps will declare their dependency on them via Maven.)
app-jpa-module (Contains definitions for JPA Entities that represents you database tables. Depends on the core-jpa-module)
app-web-module (Holds the pages, Controllers and Converters for this application.)
I think you got the idea. Things tend to be loosely coupled and you may organize your projects as you like.
This is just a simple example to illustrate. I didn't explained a lot about Maven but if you're interested I think it will help you indeed.
I hope it gives you some ideas and may help you in any way.
[]'s
If you can run all the sub-components using the same set of dependencies, you may find it helpful to migrate to a Maven build.
With Maven, you can define a top-level project that manages all the 3rd party dependency versions in one place, so all modules are built, tested and deployed against the same library versions. You are also likely to find Maven a good fit for the multi-module approach you have adopted, as it ensures that a project is rebuilt correctly if one of its dependencies changes.
You would still be able to use dynamic web projects as before; Eclipse will automatically deploy the DAOs as part of the service project (IIRC you need to characterise the DAOs as utility modules).
If you do go down the EJB root, you are correct that each EAR will get its own class-loader, and can therefore use a varying set of dependencies. However, in your position I would tend to look at improving your dependency management first - it'll probably be cheaper and easier.
Is it possible to use the Guava libraries on a project done with both GWT and Google AppEngine?
I see that the individual jars (the standard Java one and the GWT compatible one) have the same package naming hierarchy. How do these integrate in a GWT+AppEngine projecT?
Yes it is possible. A few Guava classes won't be usable on AppEngine because of the restricted sandbox your app will run in, especially those in the .io package like Files (you will be able to read stuff but not write it).
Are you worried about deploying both jar files and having a conflict? If so, I think it will be fine - when you compile your GWT application, it turns into javascript, so you wouldn't necessarily be deploying the GWT compatible jar, just the normal one.
There won't be any conflict as the gwt one will be used by true DevMode client-side and the GWT compiler, the "normal " one will live in your WEB-INF/lib and be loaded (in DevMode) in a different classloader. It thus depends entirely on your project and build setup.
That being said I never tried it within the same Eclipse project. I always use distinct client and server projects, and -noserver in DevMode.
I am currently porting a framework for building applications on J2ME to Android. This framework consists of several projects that compile to libraries (jars). Each individual JAR can contain graphical data (resources, J4ME screens, etc.). Every project generally has a well defined entry point (module). When someone wants to build an application using the framework he must only create a Midlet project and add library dependencies and use the imported classes.
We have been using the same approach to develop the Android framework. In this case we have only used normal Java Projects inside Eclipse that compile to jar libraries. These projects have dependencies with the Android Framework (android.jar). When building a new application we create an Android Project inside Eclipse and add the dependencies.
Our next step is to build more advanced modules for Android that can also contain graphical information (Activities, Dialogs, Literals, Drawables, etc.). So far only an Android Eclipse project was needed (the end application), that contained all the graphical-related classes and resources. It seems that when using resources (literals, drawables, etc.) the only approach is to create an Android Application, since the resources are only referenceable by means of an integer handler automatically created by ADT plugin (R.XXX). So building graphical modules may not be built by means of plain Java jar projects.
Android developer information explains that modular applications are feasible, but I have not found a concise tutorial explaining the process, but some tips such as how to prevent an error to ocurr when an application invokes an intent made available by other application. This is valid when building applications that use resources from other applications. I do not need several installed applications on the system, but one built from several components.
Has anyone experience developing with similar requierements? Any good tutorial or tips to start out?
It seems that the only available way is described here as hinted by the accepted answer of this other question.
The solution however is rather new (it only works with latest Android SDK tooks R6 and SDKs 2.0.X are left out of support). It has some major caveats on which I hope Google is already working:
No binary library linking. This means that the main application needs access to sources (in Eclipse implies having all the linked library projects open).
The names of resources (layouts, drawables, etc) are treated globally. This means that if you have two "main.xml" layouts, only the most relevant (uppermost in library list) will be used.
Missing funcionalities/BUGs. The documentation states that exported activities of a library project must only be declared in AndroidManifest.xml of library project. This does not work in current version. Comments inside TicTacToe example hints that this is the desired working, but for current release of Android Tools used activities from library projects must be explicitly defined in AndroidManifest.xml of main application project.