The maximum unit of management is extended from a node to domain.

Node, which is composed of one manager with multiple containers, used to be both the minimum and maximum unit of management. A domain, which is composed of multiple servers, has become the maximum unit of management.

Domain is composed of a special server called DAS (Domain Administration Server), which manages multiple servers in a domain, and MSs (Managed Servers), which services the actual applications. For more information, refer to JEUS Domain Guide. "Chapter 1. Introduction to Domains".

All the existing console commands were integrated in jeusadmin. For more information, refer to "JEUS Reference Book".

Configuration files, which were divided into multiple configuration files and system properties, have been integrated into one domain.xml file. The configurations can be changed using the jeusadmin or WebAdmin.

All configurations for server JVM has also been integrated into the domain.xml file, and a temporary process Launcher was introduced that reads JVM options from the XML files to send them to the server JVM. For more information, refer to JEUS Server Guide. "1.6. Launcher".

With the introduction of domains and the integration of configurations, the directory structure has also changed. For more information, refer to JEUS Server Guide. "1.5. Directory Structure".

The STANDBY and SUSPENDED states were added.

When a server starts, if distributing a registered application fails, the server remains in the STANDBY state, unable to go into the RUNNING state. If an administrator intentionally executes the Suspend command on a server to stop all applications, the server goes into the SUSPEND state. For more information, refer to JEUS Server Guide. "3.1.1. Life Cycle of Managed Servers".

With the introduction of the domain structure, a function where DAS uses SSH to restart servers was added to allow DAS to be able to restart a server on a different machine.

Servers are allowed to start/terminate the required engine services, as it is better for the server, and not the user, to decide which engine services are required to run an application.

Configuration of servers in a domain can be automatically synchronized.

In JEUS 6 or earlier versions, nodes in a cluster had to be synchronized manually, but starting from JEUS 7, DAS automatically synchronizes all the configurations of servers in a domain or cluster. For more information, refer to JEUS Domain Guide. "1.3. Composition".

In JEUS 6 or earlier versions, the node must be restarted to apply the configuration changes, but starting from JEUS 7, configuration changes can be applied in real time without restarting the server. For more information, refer to JEUS Domain Guide. "Chapter 3. Configuring a Domain".

In JEUS 6 or earlier versions, monitoring is only possible in unit of a node, but starting from JEUS 7, multiple servers can be monitored in the unit of a domain or cluster.

Thread pools, which were each used by a service on the server, have been integrated into one to increase thread reuse. A function has also been added to reserve a certain number of threads in order to prevent important services from not receiving a thread because they are all in use.

Starting from JEUS 7, the domain structure was introduced, replacing the concepts of managers and containers.

In JEUS 6 or earlier versions, JEUS manager and engine containers had to be managed on the same machine. Starting from JEUS 7, with the introduction of domains, the constraint was removed and DAS was introduced to manage the domain.

The server that runs the actual application services is called a MS, which correspond to an engine container of JEUS 6 or earlier versions. Application services can also be run on DAS, but this is not recommended.

Since DAS manages domains, it provides additional services besides MS services. For more information about DAS and MS services, refer to JEUS Server Guide. "1.2. Domain Administration Server (DAS)",JEUS Server Guide. "1.3. Managed Server (MS)".

Starting form JEUS 7, DAS and MS servers are all started through the launcher.

In JEUS 6 or earlier versions, JEUS manager and engine containers must be on the same machine. Starting from JEUS 7, the constraint was removed, and servers are started by receiving the configuration file from a remote DAS. For more information, refer to JEUS Server Guide. "1.6. Launcher".

Server state can be managed more thoroughly than in JEUS 6, and users can take actions according to the current status using the jeusadmin or WebAdmin. For more information, refer to JEUS Server Guide. "Chapter 3. Controlling and Monitoring JEUS Servers".

Starting from JEUS 7, the concept of domain was introduced so multiple servers and clusters can be managed in an integrated way. The server, which manages domains, is called DAS and the server, which run the actual services, are called MS.

If JEUS is installed, the default domain will be created and DAS will be configured. The domains and MSs can be added if necessary.

The directory structure was changed according to the structure changes. For more information about the domain structure, refer to "JEUS Domain Guide".

All configurations of a domain should be changed using DAS. Note that if configuration is changed directly by editing the XML file without using DAS, the domain may not function normally.

To prevent multiple users from simultaneously editing the same configuration, a lock must be obtained when using DAS. For more information, refer to JEUS Domain Guide. "Chapter 3. Configuring a Domain".

MSs on a domain can be started or terminated from DAS. For more information, refer to JEUS Domain Guide. "Chapter 4. Server Lifecycle".

Enables DAS to execute MSs using SSH.

The configuration must be set to allow SSH access using a private key on the machine where MS will boot prior to booting. DAS also must be configured to have access to the related information.

If configuration of MS is completed, the MS can be started through DAS. If the MS is terminated abnormally, DAS will detect it and restart it.

During undeployment, if previous request is processing, the undeployment will wait for the request to be completed and then proceed. This is called graceful undeployment. JEUS 7 supports graceful undeployment with multiple options.

Supports graceful redeployment that updates already deployed applications without stopping the applications. The graceful redeployment function applies only to standalone web modules.

For more information, refer to JEUS Applications and Deployment Guide. "Chapter 2. Graceful Undeployment and Redeployment".

Supports an installation function that uploads applications to DAS.

Persistent deployment is the default type of deployment.

Grants an ID to an application to ensure the uniqueness of the application in a domain.

Managed Server synchronizes application files with DAS.

Application libraries can be set for each domain. (DOMAIN_HOME/lib/application)

Application repositories can be added to a domain to deploy the applications without installing the applications on DAS.

Applications can be deployed by specifying absolute path. This function is provided for convenience in a development environment, and is not recommended to use in a production environment.

Clusters can be targets of deployment. If "All Target" is selected, the applications will also be deployed to DAS and there are constraints on the command. Thus, it is not recommended to use it in a production environment.

When starting/stopping an application fails, DAS retries to start/stop the application.

If packaged applications are not found at boot-time deployment, previous deployment images will be reused.

All screens were newly created to work with the domain structure,

Editing and dynamic modification support using Lock & Edit

Some jeusadmin commands can be used in WebAdmin through Web Console functions.

JEUS manuals can be displayed in WebAdmin.

JEUS 7 web engine supports new specifications, including Java Server Faces 2.0 (JSR314), Java Server Faces 2.1, Servlet 3.0(JSR315), JSP 2.2(JSR245), Expression Language 2.2(JSR245), Contexts and Dependency Injection for the Java EE platform(JSR299), and Dependency Injection for Java(JSR330).

When an application is deployed in an exploded mode to NAS or a remote device, and the application is shared by multiple web engines, the server might hang due to JSP compilation if JSP is changed when the workload is heavy. To minimize occurrences of hanging, a function was added that only allows one web engine to compile the changed JSP. The other web engines can provide the service using the existing version until the compilation finishes. For more information, refer to JEUS Web Engine Guide. "4.3.1. Reloading JSP Files".

Only decompress the files among the jar files in the WEB-INF/lib/ directory that are related to META-INF/resources to a separate location on the server and service the resources. The resources can be obtained using the getRealPath(), getResource(), getResourcePaths() APIs as defined in the ServletContext API. This function is also used to provide the jsp and image files as libraries.

When developing a web application, if the servlet classes are changed frequently, the web application can be redeployed to apply these changes, but this process is time-consuming. If this job is repeatedly executed, the consumed time can be substantial. To reduce this time, for minor servlet class changes, JEUS 7 dynamically updates only the classes modified in the web engine. Since this function is not supported for all changes, the constraints must be checked and this function should not be used in a production environment.

For more information, refer to JEUS Web Engine Guide. "Chapter 9. Reloading Classes at Runtime".

Limit on the post data size

Limit on the number of parameters for GET/POST requests

Limit on the number of headers for a request

Limit on the size of a header

Limit on the size of a query string

Provides the service using the newly redeployed application without stopping the current application. For more information, refer to JEUS Web Engine Guide. "1.6.10. Logs".

Supports Common Log Format as the default access log format. For backward compatibility, the log format of JEUS 6 is also supported. For more information, refer to JEUS Web Engine Guide. "1.6.10. Logs".

Access logs can be configured for each virtual host. For more information, refer to JEUS Web Engine Guide. "1.6.10. Logs".

WebAdmin can be enabled/disabled dynamically. For more information, refer to JEUS Reference Book. "4.2.3.12. disable-webadmin".

Some web engine configurations can be applied dynamically. Such configurations are as follows: monitoring within web-engine.xsd schema, min and max of the thread pool, number of webtob-threadpool, format, exclude-ext, and enabling of access-log.

javax.servlet.http.HttpServletResponse.sendRedirect(String location) API can be used to apply the policy that changes locations to absolute URLs. For more information, refer to JEUS Web Engine Guide. "3.3.6. Configuring Web Security".

With the introduction of GMS, a backup server can be decided according to the current server status, using static configuration.

Considers node information and decides on a different machine as the initial backup.

Encodes sticky information that is attached to session cookies to prevent the information from being exposed.

Session server can run simply through cluster configuration.

HttpOnly: Since browsers can only use cookies for HTTP requests, cookies are not exposed through the script.

This guarantees the order of the messages that are produced to a queue, and the order has a higher priority than that defined in the JMS 1.1 specification.

This guarantees that the messages in a queue are consumed in the order they were produced in a single server or a cluster situation.

If certain messages are specified as a group, the messages are guaranteed to be delivered to a single client at once after being produced to a server.

This can be used when a collection of messages, and not an individual message, is useful.

Sorts the messages in a queue or a durable subscription, by using the user-specified key.

Automatically delivers messages between destinations of different vendor or different JMS provider version.

When an error occurs to an active server, the standby server starts to provide the services on behalf of the active server. If the active server is recovered, the active server continues to provide the services.

Connection Distribution: The Connection Factory selects servers using the round-robin method.

Message Starvation Resolution: When trying to consume messages from a server with no messages, the other servers internally send message to be able to send to the client.

JAX-WS 2.2

JAXB 2.2

JAX-RS 1.1

Web Services for Java EE 1.3

Support for additional WS expansion stacks such as WS-Addressing, WS-ReliableMessaing, WS-Security, and WS-Policy

The existing data source management structure was changed due to domain structure changes and manager/container integration.

Each MS manages data sources registered to it, and DAS works with the MS to manage all data sources of a domain. For more information, refer to JEUS Server Guide. "6.3. Management of Data Sources and Connection Pools".

Supports dynamic update for JDBC data sources and connection pool configuration.

When the configuration is changed, the change will apply at runtime without a server restart. This applies to jeusadmin and WebAdmin. Fore more information, refer to JEUS Server Guide. "6.6. Dynamically Changing Data Source Related Configurations", and JEUS Server Guide. "6.7. Dynamically Changing Cluster Data Source Configurations".

In Java SE 6, the JDBC specification was changed to version 4.0.

When JEUS is used in a Java SE 6 environment, the JDBC 4.0 driver and its related functions are supported.

Supports Java Persistence 2.0 and provides EclipseLink 2.3. Fore more information, refer to "JEUS JPA Guide".

Supports JCA 1.6

The new connection requests from clients are changed to use the integrated network layer. Thus, three listeners do not need to separately configure network related settings, but only one network listener needs to be configured for each server through the server-listener-ref setting.

The attempt to deploy to non-existing virtual host will fail. Previously, the default virtual host was used, but it was determined to be ambiguous. Also, the same web application cannot be deployed to multiple virtual hosts.

The function that pre-compiles the JSP files of already deployed web applications was replaced with the jspc command of jeusadmin.

A resource servlet can be mapped to a particular URL to provide services. For more information, refer to JEUS Web Engine Guide. "3.3.5. Configuring Additional Functions".

The information about servlets, filters, and listeners of deployed web applications can be displayed in jeusadmin and WebAdmin. For more information, refer to JEUS Reference Book. "4.2.6.3. application-info".

In AppCompiler, a separate check file called .precompiled_result_file is created in the .warjspwork directory that is created for each web module. The modified time of this file will be compared with that of the in _generated_ file, which generally exists in the server, to determine whether to copy the results of JSP from the .warjspwork directory. This resolves the problem of duplicated copies caused by the time difference due to a prolonged compilation time.

If the deploy command is executed, applications will be deployed at runtime and the deployment information will be written in the configuration file, which is used to deploy applications when rebooting.

When an application is on a shared disk, the -shared option can be used when deploying to prevent unnecessary file copying.

The auto deployment function is not supported in a domain environment.

The jeus-application.xsd file does not share configuration with the domain.xml file. It is only used as the schema of the jeus-application-dd.xm file.

Resolved so that a commit is not possible after transaction timeout

Resolved so that JDBC connection cannot be used after transaction timeout and a commit is not possible when EJB transaction propagation occurs.

The default handler of JEUS Logger was changed to a file handler. By default, without configuration, all log messages are written in the default log file.

All the servers of a domain share the security configuration of DAS. In other words, the same security services will be running on all the servers, and the user account information and permission configuration are shared.

For more information about security system configuration, refer to JEUS Security Guide. "Chapter 2. Configuring the Security System".