We have a large application deployed inside a huge war. Inside this package we have about 900 services using javax.jws.WebService, those guys impact the deployment time because when war file is put there, server starts to load any service!
There is any way to do some kind of "lazy load" on that?
Regards
Not that I know of. You can do some things to the ear file to get it to deploy faster but this can get quite involved. Or you could break it into multiple ear files. Some tuning options:
Mark modules with no annotations as metadata-complete so they won't be scanned.
Tune which packages are scanned: https://www.ibm.com/support/knowledgecenter/en/SSAW57_8.0.0/com.ibm.websphere.nd.doc/info/ae/ae/trun_app_reduce_annot.html
Rebuild webservices to include the wsdl with the service to avoid wsdl generation at deploy time.
Related
We are deploying our application war [180 mb] to IBM Websphere admin 8.5.5.9. It takes around 30 min to deploy a war.
In Weblogic there is a option for deploying a war, that is we don't need deploy a war second time onwards, so we just replace the updated war in that path and it takes a war from that path second time. Like, Is there any option in websphere. Please help me to resolve this.
This page Options for accelerating application deployment gives you several options for accelerating deployments. Article is to big to quote it here.
As alternative you can also do partial updates if you only need to change several files.
Is it possible in Jboss deploying a ear and war file in the same server instance? If so any good source to get started? Any suggestion.
I have two applications deployed under my default deploy folder of jboss. I am running one application from which i have to call the other application to get some data. Is this possible? If so how to get started??
It is actually recommended that you only put 1 application in a server instance as a time. That said, I have had multiple ears and wars running in the same instance while I am developing. But for production it is better to separate them out. Since there is no extra cost involved this makes it easier to observe and debug apps.
Do you have a specific reason for wanting them to run side by side?
What version of JBoss are you running.
More of a standard practice questions:
Is there any difference in deploying an app as EAR vs WAR? How do you decide? (I know WAR is just a web application may or may not have Java EE features like messaging)
Lets say I have a Spring MVC application stack with Hibernate (MySQL DB), should this be deployed as a War or EAR?
When do we need to worry about JBoss deployment descriptors, if I am not using EJBs. (Just Spring MVC). Lets assume I have JMS as well. Do we need to configure/update/create any other JBoss related config files?
When we package our application EAR/WAR, it include EVERYTHING that we need for our app. Is there a scenario where we need to keep some config / xml files outside of this archive in a specified JBoss folder?
Is it common practice to deploy directly from Eclipse or better to use Ant, etc? Advantage / Disadvantage?
Obviously, I am a newbie :-). Trying to understand this.
1.
This is not always an easy decision, but for beginners and for small projects I would say it's nearly always a WAR. The reason for using an EAR is mainly to isolate a business layer from a UI/Web layer. See this question for more details: How can one isolate logical layers of an Java EE application
2.
I might be mistaken but I think that Spring people typically prefer WARs.
3.
JBoss (vendor) specific deployment descriptors are mostly needed to configure so-called "administered objects" and security. Sometimes they can be used for extra features that are not covered by the Java EE specification (e.g. setting the web root for a WAR). Administered objects are typically data sources (connection to a database) and JMS destinations (queues and topics).
In the traditional Java EE approach these have to be created as far away from the code as possible, which typically means a system admin would create them inside the target AS using some kind of GUI or admin console. In this setup, you as developer would throw a WAR with "unresolved dependencies" over the wall, and a system admin (or "deployer") would then spend days figuring out what those unresolved dependencies should be.
If the communication is relatively good between developers and deployers, the WAR or EAR might be thrown over the wall together with a readme-file, that at least gives some insight into which resources are needed. Depending on the organization the development team might not get any access or feedback about how those "unresolved dependencies" have been resolved. E.g. a data source with a max of 5 connections may have been created, but this may be insufficient if some code does say 10 parallel queries. Without the development team knowing the exact data source configuration, some classes of runtime problems and performance issues may be relatively hard to solve.
To mitigate these problems, some vendors, for some artifacts, offer the developer to create those "unresolved dependencies" instead using proprietary deployment descriptors which are then embedded in the WAR or EAR. For simple local JMS destinations this is then in most cases the end of it, but for data sources there is a little bit more to it. Namely, there has to be a mechanism to switch between data sources for different stages such as Dev, Beta, QA, Production etc. Additionally, it's rarely a good idea to have production passwords in the source code.
If you have a simple app that you want to try out locally, stages and production passwords are not a concern. If you deploy for a (large) company it is.
In Java EE 6 you can define a data source using a standard descriptor (web.xml, ejb-jar.xml or application.xml), and in Java EE 7 you can do the same for JMS destinations. There is no standard way to configure those based on stage, but there is a glimmer of hope that Java EE 8 will address this (see e.g. JAVAEE_SPEC-19). Vendors are not universally happy with those standardized methods, and their main documentation will almost always extensibly tell you how to do those things using their proprietary tools and descriptors, and if you're lucky as a small note tell you there's a standardized way (and then sometimes downplay that or scare you by saying it's not recommended to be used in production).
4.
See answer to 3 mostly. One option to solve the problem of how to switch between stages and keep production passwords out of the WAR/EAR, is to have the full definition of said data source inside the AS (inside JBoss in your case). Every AS installation is tied to a specific server in this setup. If data sources need to be updated, removed or new ones added, you have to communicate with your operations team (if any). As said, depending on your organization this can be anything between trivial and practically impossible.
5.
When developing you most often use your IDE to do a deployment. For production you would never do that. For production you may build with Ant (or Maven) and deploy via something like Jenkins, or e.g Chef.
Check here : .war vs .ear file
If you read the preceeding response, you'd guess that "WAR" it is.
Deployment descriptor are needed to manage the modules of JBoss, if you don't have any conflict or don't need any tweaking, you won't need any deployment descriptor.
You may need to play with some JBoss file if you want to add modules to JBoss, or configure datasources, etc. Read the JBoss documentation for more info.
You can deploy from eclipse during your development phase, but as your other environments (qualification, production, test, etc) should be separeted from your developing one and that they won't have any eclipse installed on them, you should get used to manage your server from the command line and drop your war's in the right directories.
It's a short answer, but I hope it will help.
Read JBoss documentation for more info.
To reduce database hits, I've used static variables to store data from database.
At time of WAR deployment this data is stored in these variabes as it is not changing so frequently.
This scenario was working fine as the scope was with only single a WAR. Now I have another application where I need access to these varibles
But due to different application scope,I'm unable to access them in another application.
Also I'm having an EAR which encloses both above WAR and one JAR containing some common buisness logic of both WARs.
So under EAR is it possible to share these variables via JAR or using some different approach?
If any javaEE concept can help in this scenario, then please let me know about it also.
I'm using maven with Jboss7.1.1.Final for this
You should use Infinispan, the built-in caching mechanism of JBoss 7 https://docs.jboss.org/author/display/ISPN/Getting+Started+Guide+-+JBoss+AS+7. Caching data in static fields is generally frowned upon in Java EE.
However should you still want to cache your data in static fields you need to make sure the class with the cache was to be shared across all WARs. This means you have to create skinny WARs.
Looks like you need an Enterprise Caching Solutions. There are lots of choices on the market. They include but not limit to
Open Source framework
Memcached
EHCache
Infinispan (mentioned by Phillipe)
Commercial product
Oracle Coherence
GigaSpaces XAP
GemFire
For your second question, as long as your JAR is deployed in the EAR/lib folder, you should be fine.
I have heard a few people say that deploying a portlet war file (or perhaps any war) that includes a lot of large jars can cause performace issues because all those jars get loaded into memory. If you have several wars, all of which include a ton of large jar files, your system will get bogged down.
I'm trying to get my head around why this is true - and I haven't found anything that explains it in a way that I get it. Maybe I'm searching for the wrong terms which is why I'm not finding much information. Can anyone explain what exactly is happening when a portlet gets instantiated and if indeed those jars start taking up memory?
The short response is: yes, deploying a war file with a lot of jars "could" cause a performance issue. It does not matter if the war contains a portlet or a standard web application.
But in my opinion you should not worry about this prematurely, because there are easy solutions for this problem.
When a portlet or any webApp is loaded into the server it loads the classes of the main jar into the "Permanent generation" region of the heap (memory assigned to the Java process) of the web server. This region stores the code that is executed. When these classes use code from other jars, their code is also loaded into this region.
If this regions is filled up, you will get an OutOfMemoryError exception.
The solutions for your problems are easy:
Dedicate more memory to your memory (parameter -Xmx of the JVM)
If you have several .war files with the same jar files in them, remove those jars from the war files and put them in the directory where all the common libraries of the Web Server are located. The location of this directory depends on the Web App server that you are using.
So, you should not worry about this problem because it has a solution.
This PDF Memory Management in the JavaHotSpot™ Virtual Machine explains how memory management works in Java. It applies to regular Java apps and Web applications.