Jakarta EE қолданбаларын жинақтау үшін EAR форматы
EAR (file format)
Jakarta EE қолданбаларын біріктіру үшін EAR форматы туралы біліңіз. Модульдерді бір архивке жинау, таратуды жеңілдету, құрылыс құралдары туралы ақпарат.
Ағылшыншамен салыстырыңыз: абзацты басыңыз — түпнұсқа терезеде ашылады. Абзац астындағы EN түймесі оны мәтін ішінде көрсетеді.
Мазмұны
Кіріспе
EAR (Enterprise Application aRchive) – Jakarta EE бір немесе бірнеше модульді бір архивке біріктіруге арналған файл форматы, бұл әртүрлі модульдердің қолданба серверіне бір уақытта үйлесімді түрде орнатылуын қамтамасыз етеді. Оған қоса, модульдерді орнату тәсілін сипаттайтын орналасу дескрипторлары деп аталатын XML файлдары да кіреді. EAR файлдарын жасау үшін Ant, Maven немесе Gradle қолданылуы мүмкін.
EAR (Enterprise Application aRchive) is a file format used by Jakarta EE for packaging one or more modules into a single archive so that the deployment of the various modules onto an application server happens simultaneously and coherently. It also contains XML files called deployment descriptors which describe how to deploy the modules. Ant, Maven, or Gradle can be used to build EAR files.
Файл құрылымы
EAR файлы – бұл ear кеңейтіміне ие стандартты JAR файлы (демек, Zip файлы), қосымшаның модульдерін көрсететін бір немесе бірнеше жазбалары бар, сондай-ақ бір немесе бірнеше жөндеу сипаттамаларын (deployment descriptor) қамтитын META-INF деп аталатын метадеректер каталогы.
An EAR file is a standard JAR file (and therefore a Zip file) with an ear extension, with one or more entries representing the modules of the application, and a metadata directory called META INF which contains one or more deployment descriptors.
Сыныптық оқшаулау
Көптеген қолданба серверлері Java classloaders-тің оқшауланған ағашы ретінде орналастырылған EAR файлынан сыныптарды жүктейді, бұл қосымшаны басқа қосымшалардан оқшаулайды, бірақ орналастырылған модульдер арасында сыныптарды бөліседі. Мысалы, орналастырылған WAR файлы EAR файлының құрамындағы JAR файлында анықталған сыныптардың инстанцияларын құра алады, бірақ басқа EAR файлдарындағы JAR файлдарындағы сыныптарды құра алмайды. Бұл мінез-құлықтың негізгі себептерінің бірі - статикалық синглетонды (мысалы, Log4J) қолданатын қосымшаларды толық ажыратуға мүмкіндік беру, әйтпесе бұл бөлек қосымшалар арасындағы конфигурацияны шатастыруы мүмкін. Бұл сонымен қатар әртүрлі қосымшалар мен кітапханалардың әртүрлі нұсқаларын қатар орналастыруға мүмкіндік береді. JBoss қолданба серверлерінің 5-ші нұсқасына дейін орналастырылған компоненттер оқшауланбаған. Бір EAR файлында орналастырылған веб-қосымша басқа EAR және WAR файлдарындағы сыныптарға қол жеткізе алатын. Бұл біршама даулы саясат. Unified Classloader дизайны жұмыс істеп жатқан қосымшалар арасындағы байланыс шығындарын азайтады, өйткені сынып деректері сілтеме немесе қарапайым көшірме арқылы бөлісе алады. Бұл сондай-ақ әзірлеушілерге кластық жүктеушілердің ағашы тудыра алатын проблемаларды түсіну қажеттілігін жояды. Дегенмен, ол тәуелді кітапханалардың әртүрлі нұсқаларын жеке қосымшаларда орналастыруға мүмкіндік бермейді. JBoss 4.0.2 иерархиялық кластық жүктеушіге ауысты, бірақ 4.0.3 нұсқасында кері үйлесімділік себептерімен біріктірілген кластық жүктеушіге қайта оралды. Бұл мінез-құлықты өзгерту үшін конфигурациялық параметрлер бар. JBoss 5.x, 6.x және 7.x енді Unified Classloading қолданбайды.
Most application servers load classes from a deployed EAR file as an isolated tree of Java classloaders, isolating the application from other applications, but sharing classes between deployed modules. For example, a deployed WAR file would be able to create instances of classes defined in a JAR file that was also included in the containing EAR file, but not necessarily those in JAR files in other EAR files. One key reason for this behavior is to allow complete separation between applications which use static singletons (e. g. Log4J), which would otherwise confuse the configuration between separate applications. This also enables different versions of applications and libraries to be deployed side by side. The JBoss application servers before Version 5 were notable in that it does not isolate deployed components. A web application deployed in one EAR file would have access to classes in other EAR and WAR files. This is a somewhat controversial policy. The Unified Classloader design reduces communications overhead between running applications, as class data can be shared by reference or simple copies. It also allows developers to avoid having to understand the problems that a tree of classloaders can create. However, it prevents different versions of dependent libraries from being deployed in separate applications. JBoss 4.0.2 switched to a hierarchical classloader, but in version 4.0.3 it reverted to a Unified Classloader for backwards compatibility reasons. There is now a configuration option to change this behavior. JBoss 5. x, 6. x and 7. x no longer use Unified Classloading.