I need to create 2 war applications deployed on tomcat server.
One of the applications have the exact same logic and code as the other application but with added changes to the view and controllers.
Then App1 and App2 will have the same code to access data and I don't want to duplicate code.
My idea is create 2 WARs and these WAR files should use a library or other project (I don't know) that has access to the database.
Which solution is the best for performance?
Option 1
If you are sharing code (and it's a big piece of code, which drives you crazy while uploading the war-files) it may be an option to create a jar containing the code and add the jar file to tomcats library-folder, which is ${CATALINA_BASE}/lib/
Note that this is usually not something you want to do lightly, because that jar file will be available to ALL war-files on the tomcat, creating possible namespace-problems.
Option 2
If sharing the code with all the projects on the application-server is not an option you'll have to add the jar-file to the projects and add it into it's classpath (which happens automatically within eclipse if you add the jar into ${PROJECT_ROOT}/WebContent/WEB-INF/lib).
Preformance-wise this doesn't really make a difference since tomcat will load the class-files, which are not very big. The instances might be, but the type of deployment doesn't really have an impact upon instances.
If you want to use the same classes for both projects just simple create one .jar file which will contain those classes. Then add that .jar into your web projects' classpath and use it in both.
You can extract the common part out, and make it as a jar. And then two wars use this jar as library.
If you used maven for building your wars, it would be easier to build a project hierarchy.
something like:
parent
|_common(jar)
|_war1
|_war2
Related
When we deploy an application to an application server like Wildfly, Tomcat, etc, it puts all of our source code on a folder named classes inside the WEB-INF folder.
Using Eclipse, we can change this folder destination on the Deployment Assembly menu, inside the project properties menu.
But I would like to do an configuration to use the same structure that we have in the real project (not in the deployed one). For example, on a maven project, we have an structure like
myproject/src/main/java/com/mydomain/myproject/model/controller/mb/IndexMB.java
So, how can we have a structure like
myproject.war/WEB-INF/src/main/java/com/mydomain/myproject/controller/mb/IndexMB.class
in the deployed project?
Looks like the files destination could be achieved changing the destinations on the Deployment Assembly menu, but unfortunally the managed bean could not be instantied or called.
How can we perform this?
Motivations
Or OCDs =)
I'm creating a class, named Router, that will be very important and essential to the system. This class will provide the routes for all system folders and packages. I will use this class to configure database connections, log4j, prettyfaces, and so on. So, for example, if I put the log4j.properties file in src/main/resource/configuration/logger/log4j.properties, I will use the Router class like new File(Router.getInstance().get('src.main.resource'),'configuration/logger/log4j.properties'). This class will be essential and a workaround could be done, to find the files even on a deployed or non-deployed system, but keep the things with the same hierarchy would be awesome.
I would like to keep the things organized and I would like to control where each created file will be put and find a way to use it programatically, if needed. Just put all files on the root folder (even on the non deployed version) looks very messy to me. For example put the log4j.properties in the root, etc.
Change the default behavior. If I have a source folder, that not contains java classes, like images, properties files, json files; these aren't classes, so, these should not be in the classes folder. I think the best way is to configure to each file to be deployed on a proper folder and the system learns how to get and operate with it.
The Router class will be used on application servers (that see the deployed folders) and in java applications and junit tests, so keep it together will be prefereable.
I am building a desktop application with NetBeans 8.0.2. For my application, I have to manage 3 differents projects : The main project, and two "tool" projects that are linked to the main.
When I run the main project, it will check the JARs present in his classpath in order to retrieve the Manifest files and do some work with.
In order to have my application run correctly, it has to see the two linked projects' JARs but it doesn't, because NetBeans deals with the compiled classes of the project instead of the JAR (for debugging purposes I presume).
I found nothing about it on the Oracle documentation, and the only thing looking a bit like what I search is to create a big-fat-JAR by using another component.
Is there a way to tell NetBeans to "compile the linked projects and use the JARs instead of the .class" files ? Thanks in advance
EDIT : Here is an example when I add the project with "Add Project .." option
/C:/Users/xxxxx/Documents/GuiceProjectsRD/xxxReaderRef/build/classes/
And here is an example when I add the JAR
/C:/Users/xxxxx/Documents/JavaLib/xxxReaderRef.jar
When I add the JAR, I have the ".jar" extension which helps me identify a JAR and then look into it for a Manifest. When I add the Project, there is no path to the JAR but only to the compiled classes, and I can't work with that.
I would not depend on the Manifests in Jars since you then get this kind of issues.
Have a look at the Typesafe Config library. It's a small 100% pure Java library to work with Json/Hokon configuration.
Instead of relying on a Manifest, create a 'reference.conf' in each tool project. In your application, create an 'application.conf' (if needed). Load the config via 'ConfigFactory.load()'. It will automatically search all available reference.conf's, and application.conf, on the classpath, whether in a jar or not, and merge those configs into a single configuration.
I use this approach in project to be able to plugin extension. Have for example in tool A a configuration like
tool.A.class = 'my-tool-A.class'
or used nested structures like
tool {
A {
class = 'my-tool-A.class'
}
}
Do something similar voor tool B.
Then in your application, from the Config, you can get a list of 'tool' configs and detect the available tools like that.
The question is in the title I guess. Both folders have a bin directory with some duplication of scripts, etc. Then there are multiple lib directories as well. One in the /glassfish/lib and another in /glassfish/domains//lib. It just seems odd to me and gets confusing as to where I should put classpath jars, direct env variables to, etc. Is there any specific reason for this?
Thanks
The reason for this is that it gives you the flexibility to provide libs at different visibility levels.
The folder glassfish/lib contains the libs which should be available for the whole server and all domains.
The folder glassfish/domains/domain1/lib contains only the libs which are available for domain1.
If you had a domain2, the folder glassfish/domains/domain2/lib would contain the libs which are required for domain2.
Now, as an example, if you have some libs which are required by domain1 and domain2, you can put them in the folder glassfish/lib, so they are available for the whole server and therefore for both domains.
Another example, if you have two domains, and both domains require a different version of the same lib, you have to put the specific versions into glassfish/domains/domain1/lib and glassfish/domains/domain2/lib accordingly.
As a consequence of this, you can always put your libs into glassfish/lib if you only have a single domain.
See also:
GlassFish Server 3.0.1 Guider - Chapter 2 Class Loaders
ClassLoaders in GlassFish - a FAQ
How to use 3rd party libraries in glassfish?
how can i use a shared lib in glassfish to avoid deployment of the huge libs?
I am developing a framework that needs a lot of stuff to get working. I have several folders inside of my Eclipse project that are needed
[root]
- config
- src
- lib
- serialized
Also there are important files like the log4j.properties and the META-INF dir inside the src directory.
I wonder if there is a way to distribute one JAR containing all essential files so my gui will just have to import one jar. I guess that I have to exclude the config folder in order to make the framework configurable.
I also wonder, if there is a way to move for example the log4j.properties to the config dir so that I have one config folder containg all needed configurations?
Thanks for help and advise on this matter!
Marco
Yes, but not really. You can take all your dependencies, unpack them and simply merge them into a bigger jar. This is what the maven jar plugin does if you make a jar with dependencies. The only problem is that this might result in conflicting files (suppose two of your dependencies contain a log4j.properties). This is one of the problems when doing the above with some of the spring libraries for instance.
I think someone actually wrote a classloader that allows you to bundle the whole jar inside of your jar and use it as is. I'm not sure how mature that is though and can't at the moment recall the name.
I think you're better off distributing all your dependencies separately. Setting up the classpath is a bit of a pain but surely java programmers are used to it by now. You can add dependencies to the Class-Path header in your manifest file, in simple cases. Bigger libraries have to rely on the classpath being set up for them though.
As to the second part of your question, probably dropping the conf/ directory under META-INF is enough for its contents to be picked up. I'm not sure about this. I'm fairly sure it will always be picked up if you put its contents at the top level of the jar. In any case, this is a distribution problem. You can easily have a conf/ directory inside your source tree and have your build scripts (whatever you might be using) copy the files in it to wherever is most convenient.
As to your users configuring. Try to establish some conventions so they have to configure as little as possible. For things that must be configured, it's best to have a basic default configuration and then allow the user to override and add options through his/her own configuration file.
In terms of the resources, it is possible except that if you do that you are not going to be able to load resources (non class files) from the filesystem (via a file path).
It's likely that you're currently loading these resources from the file system. Once in the jar you need to load them as class path resources via the class.getResourceAsStream or similar.
As for the dependent jars you may have, it's common practice for these to be placed as extra jars on the classpath. I know it's complicates things but developers are used to doing this. The nature of the java landscape is that this is inevitable. What the spring framework for example does is supply a bundled zip file with the core jar and the jar dependencies included.
Is your library going to be used in an EE context or an SE context? If it is an EE context then you really don't have to worry about configuration and class path issues as the container takes care of that. In an SE context it is a lot more tricky as that work has to be done manually.
I basically want to be able to deploy multiple versions of the same EAR file to the same server (Glassfish instance?) , and have a unique path to each version separating them.
From my reading on this it appears that multiple EARs deploy to the root of the web server namespace so that they can coexist if they do not have colliding context-root's of WAR's.
In my case I'd rather have that instead of everything going under "/", I'd like to be able to brand a given EAR-file build to ALWAYS deploy under a given path like "/foo-20100319" or "/foo-CUSTOMER-20010101". This can easily be done with a single WAR file just by renaming it. I do not need or want them to disturb each other.
It is my understanding that this remapping is outside the scope of the application.xml file, so I found that http://docs.sun.com/app/docs/doc/820-7693/beayr?a=view says that I can specify web-uri and context-root, but I am not certain that what I wish to do, can be specified with these in Glassfish.
How should I approach this? I have full control over the build process.
(I have found Deploying multiple Java web apps to Glassfish in one go but I am not certain how to apply this to what I need).
The application.xml allows you to map a web app that is enclosed in an ear to the context root of your choice. You can also do this with the sun-application.xml.
Since you have full control over the build process, the choice is yours.
You may want to read about the --deploymentplan option of the deploy subcommand of GlassFish's asadmin utility. It allows you to mix additional files into the deployed archive before deployment processing... So, you can create a single 'generic' ear file and a number of shorter deploymentplan files, that 'mix-in' the sun-application.xml file necessary to create a customized deployment.