• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Tim Cooke
  • paul wheaton
  • Jeanne Boyarsky
  • Ron McLeod
Sheriffs:
  • Paul Clapham
  • Liutauras Vilda
  • Devaka Cooray
Saloon Keepers:
  • Tim Holloway
  • Roland Mueller
Bartenders:

Deploy code is separate conatiner

 
Ranch Hand
Posts: 49
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hello all,

I have question regarding deployments. we have application code goes into one ear file. but in some scenarios i always hear deploy code in separate container , what it means. why we go for separate container what are the advantages.

appreciate your inputs.

thank
 
Ranch Hand
Posts: 271
15
Android Angular Framework Spring AngularJS Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi, Sireesh:

An EAR file (Entity Archive), is going to contain everything the Enterprise Application needs to run. That will include any EJBs, regular classes, HTML files, libraries, web-oriented definitions (like tag libs), and persistence code.

Already you can see a flaw in what I have written. We place all the web-oriented stuff (HTML, Servlet classes, tag-libs, CSS, etc.) into a separate container called a .war (WAR file). We put the persistence code into its own jar (.har etc.). So, assuming the alternatives are "deploy code in separate container", versus "within the ear file, have the packages as folders within the ear", then the contents of your EAR file would have all these neatly packaged WAR, HAR, etc. files, and there would be those class files. Packaging them up in their own container would make sense, within the ear file.

If instead you are talking about a separate jar file outside the ear file itself, I don't see a need for that either.
 
Sireesh Ganagam
Ranch Hand
Posts: 49
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks for the explanation. how does it matter even if i have the separate war , ear and har files in case using one application server instance ( jboss , websphere)

 
Saloon Keeper
Posts: 28486
210
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
An EAR is a package container for a multi-component web application. Its virtue is that it's a single (ZIP-format) file that contains all the components needed for a complex webapp (WARs, CARs, JARs, and so forth) so that you can deploy it as a unit instead of stuffing in each of the components separately.
 
Sireesh Ganagam
Ranch Hand
Posts: 49
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Sorry if didn't understand correctly. In order to be different container does it mean i have to use different application server instance ( jboss) for each component war , ear , car ? let say if i install war, ear it will become one container .. sorry for the confusion
 
Tim Holloway
Saloon Keeper
Posts: 28486
210
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
No, I should narrow terms. Consider a "container" to be a server (for example, JBoss). Let's refer to the deployable units (WARs, EARs, and so forth as modules.

A module may contain other modules. For example, an EAR may contain multiple WARs.

A given module is deployed as a unit. If it has sub-modules, the container that the module is deployed into will automatically deploy these sub-modules as part of the process of deploying their parent module.

If a module is deployed on multiple containers (and/or multiple times on a single container), these deployments are referred to as instances.

So the virtue of a module is that it can be deployed to a container as a single unit instead of having to install everything file by file.
 
Seriously Rick? Seriously? You might as well just read this tiny ad:
Smokeless wood heat with a rocket mass heater
https://woodheat.net
reply
    Bookmark Topic Watch Topic
  • New Topic