At the moment we use glassfish 3.1 as application server for our enterprise application. The application(s) are packed within an ear. The ear contains approximately
5 wars,
10 jars and
60 jars(ejb) .
The deployment of the ear takes more than 10 minutes. Is there any chance to tweak the deployment time of the application?
BTW: We splitted the ear already in smaller pieces. But in most cases we need the complete suite deployed.
If you are trying to reduce development time, there is two way for it for glassfish as much as I know.
First, you can deploy as a directory with asadmin deploydir. As a result of that you can change jsp files and method bodies, thanks to hot swap technology.
But the most elegant solution is using an alternative library in order to decrease the amount of deployments. There are a few alternative for this but you can use jrebel. It is quite stable. JRebel is used to reduce deployments and reloads class files on the fly by jvm its jvm agent. It has support for almost all well known frameworks.
You could be running into this:
http://java.net/jira/browse/GLASSFISH-17094
Download the latest GlassFish 3.1.2 build and see if it solves your problem:
http://dlc.sun.com.edgesuite.net/glassfish/3.1.2/promoted/glassfish-3.1.2-b23.zip
Update: GlassFish Server 3.1.2 has been released:
https://blogs.oracle.com/theaquarium/entry/glassfish_3_1_2_final
Hope this helps.
Related
I need solution to speed up maven build process.
The project is based on Adobe cq5 otherwise AEM and i have more than 10 modules in my project where the build happens in linear way.
Currently Build process takes more than 10 min to compile.
is any other specific tool available or other way to speed up the process?
Thanks
I have one suggestion,If you have 10 modules than make separate profile for each module,and build only that part in which you are changing and modifying,no need to deploy 10 modules each time unnecessarily.It will not speed up maven project build but can help you to save your time.It is a workaround but will be helpful .
Try mvn -T 4 clean install #Builds with 4 threads
Its a multi-threaded mode to run Maven and is faster. Apache documentation here.
To add to the other answers:
1) Give more memory resources to the server where the AEM instance is installed, content creation involves a lot of disk access so using SSD is a must.
2) Having a clean AEM instance helps to speed up the process. As you may know the AEM repository grows because of revisions so each time you deploy the repository size grows and it becomes slower. if it's a production environment use maintenance tools like revision clean up and compaction.
revision clean up
how to maintain repository
As per my knowledge there are no such mechanism to speed up.
better to make a build of particular module, it will deploy faster rather waiting for all 10 module to be happened.
Thanks
You can try using the suggested answers to build modules in parallel. It should speed up the build in theory.
But really there is no magic answer. You have to find the bottleneck in your build, it could be the number of dependencies, it could be a specific slow plugin, it could be hardware related, and it could be something else.
Try this: https://github.com/lptr/maven-time-tracker
It may help you find the bottleneck.
I would like to answer this question, knowing it was posted a really long time back.
Currently I am using AEM 6.3 and to recompile and deploy CORE module changes there is a simple maven trick -
This command tells us to -
run 1 thread/core
compile just the core module of the list of projects
and of course, zip package and send it to running AEM instance.
In my observation, this reduced the turnaround time by a huge margin.
WebSphere Application Server 8.0.0.0
I am using RAD to make Host Access Transformation Services (HATS) macros and deploy them as webservices on WAS. I'm a .NET developer and have no (very little) experience with WAS and Java EE.
When I was discussing some things with people who have more experience it was mentioned that we should avoid making multiple EAR files and deploying them onto WAS. It would be preferred if we could keep them as low as possible, ideal would be only a single EAR deployed. The WAR modules are fine if masses of them exist.
Is there any truth in this or would it be ok if we have more EAR files deployed on WAS?
I haven't seen any warning like that, and we run 20-30 EARs on our servers. It's definitely supported and expected that you run multiple Enterprise Applications (EARs).
I would like to know what is debug mode in jboss. I've used django before and when I turned on debug mode, any change I make while the localhost is running will be detected and refreshing the page will show the changes. Is that the same in jboss debug?
I use maven to install the project then start jboss in windows command console. How do I turn on debug mode for jboss 5.1.1?
Maven clean install takes about 8 minutes, then restarting the server is another 5-7 minutes. I am wasting a lot of time for many small changes.
You can enable remote debugging on the JVM allowing you to connect via your IDE and you can from there run your app in bebug (stop the execution and go step by step). Look on the statup script, the remote debug option has been put in comment. Debug allow you to update some class (you need to connect the IDE to it and update your class via the IDE, the JVM and JBOSS won't detect the change them self). But if you update any container managed part (EJB, persistance context, servlet) you will need to redeploy the application. So I don't think it will give you what you need.
Why do you do a clean install each time? A simple install should create your package and prevent any compilation, file copy if the source is older than the build artifact. You can also redeploy your application without shutting down JBoss. There is Maven goal for that. By default I think, if JBoss detect that the application file (ear or war) has been change (the timestamp is lower than deploy time) it will redeploy the application (some time redeploy is unfortunately not enough, most of the time class loader issue. Never get issue with JBoss as 7 but class loading has been redone).
If you can upgrade to JBoss AS 7, it is far quicker and Java EE 6 make your application lighter impacting positively the build time. But this may require to much refactoring.
I am wondering what is the recommended system requirement for using eclipse and m2eclipse plugin. I am using E8400 and 4Gb ram currently. Nearly every time I changed something in the pom.xml the eclipse IDE would hang for a while (about 1-3 minutes) before it finished. Is it normal?
Generally speaking, it is not normal.
I do all my development on a laptop with 4GB of RAM and I am able to run Eclipse + M2Eclipse + Tomcat + Flex/Flash + MySQL, etc. I change my POMs (8 of them in one project) constantly and it usually never takes more than a few seconds.
That said, depending on the size of your dependency tree it can take a while to download all the dependencies to your local machine. You can find out what is happening by opening the console view in Eclipse and selecting the Maven console within it. Check it out and report back, perhaps there will be a clue as to some other problem.
I am using RAD 7.0. My web application works with a jar(contains the backend code for our application) which undergoes frequent changes. But whenever I replace the jar in the WebInf/lib folder of the war and restart the server, it does not pick up the latest jar. It keeps referring to the previous jar. I have to undeploy, restart server several times to make the war pick up the latest jar. Has anyone come across this issue? Any pointers will be useful.
Many thanks,
RJ
Is your server configured with "Run with resources within the workspace"?
If so, switch to "Run with resources on the server" and see if this solves the problem.
I have had my share of RAD problems not picking up new code, especially on RAD 6.0 and 7.0; on RAD 7.5, IBM finally seemed to have a grip on these issues.
You can also do a server clean to force the temp and work dirs to be cleaned and the code to be republished. RAD 7 has a problems and if you can upgrade to 7.5 many get resolved in that version.