Copyright © 2011 Skyway Software
Table of Contents
List of Figures
List of Tables
List of Examples
Table of Contents
One of the goals of MyEclipse for Spring (ME4S) is to help developers write less code from scratch and use code generation more broadly, and ME4S offers the richest set of code generation options available anywhere. ME4S can generate software components for Spring MVC, Spring Web Flow, Spring Security, REST, JAX-WS, Adobe Flex, Google Web Toolkit (GWT), JPA, DAO and JSF 2.0/Primefaces. As an alternative to writing software components from scratch, ME4S helps developers generate software components that are specific to their project. In many cases the software components may be used as-is, or they may be used as a starting point for further development. Furthermore the developer can edit the ME4S templates to further customize how the software components are generated.
Scaffolding refers to the superset of ME4S's broad code generation functions, from generating a specific set of requested software components to generating fully implemented ready-to-run applications. Besides the obvious benefits of reducing application development effort and sparing developers from some of the chores of development, scaffolding is also frequently used for rapidly developing functional prototypes, learning new technologies, and application modernization projects. The ability to quickly generate a full application is very beneficial to prototyping because you can iterate on a domain model and regenerate a functional prototype in minutes. The prototype can be used with business analysts as a tool for elaborating requirements and as the starting point for development. ME4S helps many developers learn new technologies by generating contextual reference projects, which are personalized projects that are based on their own data model. This is a considerably better approach than hunting for sample projects that are often incomplete, don't follow modern best practices, and are based on trivial data models. ME4S can also be used to jumpstart an application modernization effort by leveraging application artifacts from the current system for generating a significant portion of the application components for the new system.
The MyEclipse for Spring scaffolding functionality uses the Create-Read-Update-Delete (CRUD) application pattern for generating applications that allow the end-user to manage application data. While CRUD isn't the only application pattern, it's a fairly typical application pattern. Not all web applications are satisfied solely by the CRUD application pattern, however developers find that the generated application artifacts lend themselves to being easily re-used, customized and extended. This is particularly true when the components of a scaffolded applications conform to industry best practices.
CRUD applications are tied to a domain model that is used as the input into the scaffolding engine. The domain model can exist in many forms, and the Spring Scaffolding wizard supports the use of Java beans, JPA entities, database tables, and Spring DSL Domain Objects as inputs. The output of scaffolding is a web application implemented with Spring MVC, Spring Web Flow, JavaServer Faces (JSP 2.0), Adobe Flex, Google Web Toolkit (GWT), and/or iPhone.
Code Assistants refers to a set of capabilities in MyEclipse for Spring to help developers in their day-to-day development activities. The first set of code assistants are Annotators. While most JAVA developers understand the technical use JAVA annotations, it's not always clear which annotations are available for a specific technology and when a particular annotation should be used. For example, the Spring framework has excellent support for annotation-based programming, however there are a lot of supported annotations. Some annotations are applicable to all Spring stereotypes, and other annotations are only applicable to specific stereotypes. Annotators support annotation-based development by helping a developer understand what annotations are available and in what context the annotation should be used.
See Spring Annotators, JAX-WS Annotators and JPA Annotators.
One of the other features of MyEclipse for Spring is the Spring DSL, which is an abstraction for Spring web application development. The Spring DSL defines 11 abstractions, which include Spring DSL, Model Package, Web Controller, Service, Component, Domain Object, Data Access Object, Named Query, Exception and Flow. Each abstraction has a direct correlation to one or more Java, Spring, and JPA artifacts and will generate into a distinct set of code or configuration artifacts.
This is the Spring DSL model:
Here's a high-level summary of each Spring DSL component.
Spring DSL - used for project-wide configuration of Spring DSL code generation.
Model Package - used for namespacing and grouping related Spring DSL components. A model package can contain any top-level Spring DSL elements, including other model packages. Model packages correlate directly to java packages, and Spring DSL artifacts created in a model package will be generated into a matching Java package.
Web Controller - used for defining the web layer of an application using Spring MVC and managing related files. Web Controllers are generated into @Controller annotated Spring components, a specialized stereotype for web layer components.
Service - used for defining a service layer components and managing related files. Services get generated into @Service annotated Spring components, a specialized stereotype for service layer components.
Component - used for defining a general-purpose Spring managed java bean and managing related files. A component gets generated into @Component annotated Spring components, a generic stereotype for Spring managed components with configurable scope.
Operation - used to define methods for both Controllers, Services and Components. Operations represent application logic, and they use inputs and outputs for exchanging data. Operations are generated directly in the respective Controller, Service, and Component class, and they are generated slightly differently to account for the different implementations needed for the Spring stereotypes.
Domain Object - used to define the domain model of the application and managing related files. By default a domain object is generated into a plain old java object (POJO). If a domain object is associated with a data access object, then the domain object is annotated as an @Entity (JPA) annotated class, and it's associated with a primary key class (@IdClass). Fields can be added to domain objects by using the basic data types, and a domain object can have relationships to other domain objects.
Data Access Object (DAO) - used to separate data access logic from application logic and managing related files. A DAO manages the persistence of domain objects, and it is generated into @Repository annotated Spring components, a specialized stereotype for data access layer components. A DAO can also contain predefined queries called Named Queries.
Named Query - used for defining queries for the data access objects (DAOs). Named queries are defined using either SQL or JPQL (Java Persistence Query Language), and Named Queries are generated into @NamedQueries and @NamedQuery annotations in Spring @Repository components.
Exception - used to define custom exceptions and managing related files. Exceptions are generated into exception classes in Java.
Flow - used to implement the web layer of an application using Spring Web Flow.
Each Spring DSL component has an associated editor. Spring DSL-based development consists of a developer creating instances of the Spring DSL components, and configuring them using their respective editors. When code generation is invoked, the code and configuration files managed by the respective component will generated according to their configuration.
When Spring code generation capabilities are added to an Eclipse project, a Spring DSL view is added to the project that is visibile from the Eclipse Project Explorer. This element shows a hierarchical view of the project's Spring DSL artifacts, and it can be used for interacting with the Spring DSL, including:
configuring project level code generation settings (Spring DSL double-click or right-click-->Open)
opening Spring DSL editors (Artifact double-click or right-click-->Open)
creating new Spring DSL artifacts (right-click-->New)
scaffolding (right-click-->Scaffold Spring CRUD application from...)
The Spring DSL view closely resembles the Java source code view in Eclipse. Therefore it is very intuitive and easy to learn. The artifacts are organized by Model Packages, which correlate directly to Java packages. Under a model package there are one or more Spring DSL artifacts. As mentioned earlier, a Spring DSL artifact is an abstraction that manages one or more Java code artifacts. The Spring DSL view lets you see your project at the abstraction level. If you want to see you project at the code level, then look at the source code.
This diagram shows the project the Spring DSL view of a scaffolded project. Various instantiations of Spring DSL artifacts are highlighted.
Each Spring DSL artifact has a specific editor for configuring the artifact, which subsequently influences the generation of the code and configuration files that are managed by the Spring DSL artifact. More information about the specific editors can be found in the Spring DSL section.
Table of Contents
When you right-click on an Eclipse Project, the MyEclipse menu (right-click-->MyEclipse) will have the following menu items. The top five menu items in the following screenshot are only available in MyEclipse for Spring.
When you expand the Spring DSL menu folder (right-click-->MyEclipse-->Spring DSL), the menu will have the following menu items related to development using the Spring DSL. These menu items are for eare only available in MyEclipse for Spring.
This section covers the individual menus items that are specific to MyEclipse for Spring.
Runs the Enable Spring DSL wizard.
Disables the Spring DSL. This turns off all code generation and code synchronization performed by the DSL.
Runs the Add Spring Runtime Dependencies... wizard.
Runs the Scaffold Spring CRUD Application from... wizard.
Runs the Scaffold Spring Security wizard.
Runs the reverse engineering process to (s) update pre-existing Spring DSL artifacts from updates made to Java code or (b) create new Spring DSL artifacts from the Java source files. When a project has the Spring DSL enabled, there is an Eclipse builder that monitors code changes in the project and automatically keeps the Spring DSL in sync. However there may be occasions where you want to force the synchronization (i.e. changes made outside of Eclipse).
While new flows can be created using the New Web Flow wizard, this menu lets you leverage the webflow editor for maintaining pre-existing flows that didn't originate from Spring DSL. When a project is enabled for Spring DSL, this menu item will create the webflow diagram for an existing flow. Once this is done, you'll be able to use the Webflow editor to visualize and maintain your flows.
Table of Contents
As explained in Spring scaffolding, scaffolding can generate full or major portions of an application by applying standard application patterns from a minimal set of existing artifacts provided by the developer. This wizard is used for all CRUD application scaffolding functionality.
Inputs
Relational Database Tables
POJOs
JPA Entities
Outputs - one or more application layers
Web Layer - if selected, one or more web clients
This wizard has many panels for guiding you through the scaffolding process. The wizard will dynamically determine the relevant panels based on the artifacts you are scaffolding from and the configuration of the project. The three most common scaffolding scenarios are:
Scaffolding from Java Beans
Scaffold Spring CRUD Application from... >> Select Project >> Select Artifact Type(s) >> Select Artifacts >> Select Primary Keys >> Application Layers and Packages >> Select Web Client >> Configure List Components >> Persistence Connection >> Target Folders >> Summary
Scaffolding from JPA Entities and Spring DSL Domain Objects
Scaffold Spring CRUD Application from... >> Select Project >> Select Artifact Type(s) >> Select Artifacts >> Application Layers and Packages >> Select Web Client >> Configure List Components >> Persistence Connection >> Target Folders >> Summary
Scaffolding from Database Tables
Scaffold Spring CRUD Application from... >> Select Project >> Select Artifact Type(s) >> Select DB Connection >> Select Tables >> DB Scaffolding Options >> Application Layers and Packages >> Select Web Client >> Configure List Components >> Target Folders >> Summary
The Select Project panel is for selecting the project that contains the artifacts that will be used as inputs for CRUD scaffolding and selecting the destination project for scaffolded artifacts.
Table 3.1. Scaffold Spring CRUD Application - Select Project Panel
| Option | Description | ||
|---|---|---|---|
| Project | List of all open Eclipse projects. Select the one project that should be scanned for scaffolding inputs. | ||
The Select Artifact Types panel is used for specifying which type of artifacts (i.e. database tables, JPA entities, Java Beans) should be used as inputs to scaffolding. You can select from multiple artifact types:
Table 3.2. Scaffold Spring CRUD Application - Select Artifact Types Panel
| Type | Description | ||
|---|---|---|---|
| Database Schema | For scaffolding from existing database tables (reverse-engineering of schema). You will be prompted for a database connection to select the database tables that should be used for scaffolding. Scaffolding from a database schema must be done independent of the other artifact types. When you select the Database Schema option, the other artifact types are disabled. You would need to re-run this wizard to scaffold from JPA Entities, Java Beans or Spring DSL Domain Objects.. | ||
| JPA Entities | For scaffolding from existing JPA Entities in the current project. The wizard will scan for classes that have the @Entity annotation. | ||
| Java Beans | For scaffolding from existing Java beans in the current project. The wizard will scan for non-annotated Java classes that follow the java bean convention (getters/setters for class attributes and zero arg constructor) | ||
| Spring DSL Domain Objects | For scaffolding from existing Spring DSL Domain Objects. This option is only shown when the current project has the Spring DSL enabled (using the Enable Spring DSL wizard). The wizard will scan for all Spring DSL Domain Objects. | ||
Table 3.3. Scaffold Spring CRUD Application - Select Artifact Type(s) Panel
| Type | Description | ||
|---|---|---|---|
| Database Schema | Scaffold from database schema | ||
| JPA Entities | Scaffold from JPA Entities in current project | ||
| Java Beans | Scaffold from Java Beans in current project | ||
| Spring DSL Domain Objects | Scaffold from Spring DSL Domain Objects in current project | ||
The Select Artifacts for Scaffolding panel will scan the project for specified artifact types and let you select the specific artifacts to be used for scaffolding.
Table 3.4. Scaffold Spring CRUD Application - Select Artifacts for Scaffolding Panel
| Details | Description | ||
|---|---|---|---|
| Matching Artifacts | This is a list of artifacts that are available for scaffolding from. This list was derived by the wizard by scanning the selected project or folder for artifacts that match the specified artifact type(s). | ||
| Select Artifacts | This is the list of selected artifacts for scaffolding. The artifacts are selected by adding them from the Matching Artifacts list. | ||
The Select Primary Key(s) panel is for specifying the fields for any selected Java bean(s) that uniquely identify an instance of the Java bean.
Table 3.5. Scaffold Spring CRUD Application - Select Primary Key(s) Panel
| Details | Description | ||
|---|---|---|---|
| Java Beans | Lists all the Java beans that have been selected for scaffolding and require the specification of primary keys. | ||
| Primary Keys | As each Java bean is selected, the fields of the Java bean will be listed. One or more fields must be specified as the primary key for each bean in the Java beans table. | ||
The Application Layers and Packages panel is used for selecting which application layers will be scaffolded and what package name should be used for generated Java/Spring code.
The selections on this panel depend on what you're trying to generate. By default all layers are enabled, and this will result in the generation of a fully implemented application for the web clients you select (see next panel) (i.e. Spring MVC, Spring Web Flow, JavaServer Pages (JSP 2.0), Adobe Flex, Google Web Toolkit (GWT), and iPhone). However in some cases you may be interested in only scaffolding a few layers of the application. For example you may already have implemented the JPA and DAO layer by hand or with other tooling, and you only want to scaffold the web layer and service layer. Perhaps you are planning to implement your back-end with Spring, but you want to implement the web layer with a different technology that is currently supported by scaffolding. In that case you would probably only want to scaffold the service, domain and data access layers.
Table 3.6. Scaffold Spring CRUD Application - Application Layers and Packages Panel
| Details | Description | ||
|---|---|---|---|
| Base Package | The base package name for all scaffolded application layers. The package name for all others layers will be derived from the base package. For each layer a sub-package (web, service, and dao) will be appended to the base package. | ||
| Scaffold web layer artifacts | Selected by default. Specifies whether the web layer will be scaffolded, including Spring controllers (@Controller), Spring components (@Component), JUnit tests, JSP pages, Sitemesh configurations, localization files, and web layer Spring context files. | ||
| Package (web) | The package name for all generated Java source code for the web layer. If base package is specified, by default the package name will be derived by appending .web to the base packaged. It can be overridden. | ||
| Scaffold service layer artifacts | Selected by default. Specifies whether the service layer will be scaffolded, including including Spring services (@Service), service interfaces, JUnit tests, and service layer Spring context files. | ||
| Package (service) | The package name for all generated Java source code for the service layer. If base package is specified, by default the package name will be derived by appending .service to the base packaged. It can be overridden. | ||
| Scaffold DAO layer artifacts | Selected by default. Specifies whether the data access object (DAO) layer will be scaffolded, including Spring data access objects (@Repository), JPA named queries (@NamedQueries), JUnit tests, and DAO layer Spring context files. | ||
| Package (dao) | The package name for all generated Java source code for the DAO layer. If base package is specified, by default the package name will be derived by appending .dao to the base packaged. It can be overridden. | ||
The Select Web Clients panel is used for the specifying the desired web layer implementations for the current scaffolding. The current options are for Spring MVC, Spring Web Flow, JavaServer Pages (JSP 2.0), Adobe Flex, Google Web Toolkit (GWT), and iPhone Web.
Table 3.7. Scaffold Spring CRUD Application - Select Web Client Panel
| Details | Description | ||
|---|---|---|---|
| Spring MVC | Generates a front-end using Spring MVC. See Spring MVC scaffolding blueprint for details on what gets generated. | ||
| Spring Web Flow | Generates a front-end using Spring Web Flow. See Spring Web Flow scaffolding blueprint for details on what gets generated. | ||
| JavaServer Faces | Generates a front-end using JavaServer Faces. See JavaServer Faces scaffolding blueprint for details on what gets generated. | ||
| Adobe Flex | Generates a front-end using Adobe Flex. See Adobe Flex scaffolding blueprint for details on what gets generated. | ||
| iPhone | Generates a front-end using iPhone. See iPhone scaffolding blueprint for details on what gets generated. | ||
| GWT | Generates a front-end using GWT. See GWT scaffolding blueprint for details on what gets generated. | ||
The Flex Options panel is used for the specifying configuration information specific to Flex scaffolding. Currently the only option is to specify the home directory of the Flex SDK. By default this panel specifies the Flex SDK instance that's included with MyEclipse for Spring, but you can specify a different instance of the SDK by selecting it from the file system.
Table 3.8. Scaffold Spring CRUD Application - Flex Options Panel
| Details | Description | ||
|---|---|---|---|
| Flex SDK Location | Used to specify the folder where Flex SDK is installed. Flex SDK can be downloaded from Adobe. | ||
| Flex Version | Specify the version of Adobe Flex to generate for. | ||
The GWT Options panel is used for the specifying configuration information specific to GWT scaffolding, specifically which version of GWT application should be generated.
Table 3.9. Scaffold Spring CRUD Application - GWT Options Panel
| Details | Description | ||
|---|---|---|---|
| GWT Version | Used to specify whether to generate for GWT 2.0 or GWT 2.1 | ||
The REST Options panel is used for the specifying configuration information specific to REST web services.
Table 3.10. Scaffold Spring CRUD Application - REST Options Panel
| Details | Description | ||
|---|---|---|---|
| REST / JSON Support | |||
The Customize User Interface panel is used for specifying which fields should be included in the generated list and picker UI components. Furthermore you can customize the table headers. By default the field names will be used as the table headers, but they can be changed by clicking on the field and editting the field name.
Table 3.11. Scaffold Spring CRUD Application - Customize User Interface Panel
| Details | Description | ||
|---|---|---|---|
| Table / Fields |
List all the fields sorted by domain object and web client. These are field names that will be used when generating UI components for the web layer. The default field names are derived from the underly domain objects, but the field names can be changed by double-clicking on field name and entering a new value. When scaffolding multiple web clients, each web client selected from the select web client panel will be listed separately in this table, and the configuration of one web client will by default affect the configuration of the other web clients. If you want to configure each web client independently (i.e. due to different requirements), then uncheck the "Propogate changes to all web clients" checkbox. |
||
| List | Specified whether or not the field name should be included in list UI components. | ||
| Picker | Specified whether or not the field name should be included in picker UI components. Currently this is only applicable to GWT web clients. | ||
| Propogate changes to all web clients | Specified wether the changes to one web client should be propogated to other web clients. | ||
The Specify Persistence Connection panel is used for configuring the runtime persistence connection of the scaffolded application by selecting a workspace database connection. The selected database connection properties will be used to configure the persistence connection properties for the scaffolded application.
Table 3.12. Scaffold Spring CRUD Application - Specify Persistence Connection Panel
| Details | Description | ||
|---|---|---|---|
| DB Connection | Lists all the current MyEclipse DB connections. Select the connection that should be used to configure the application's runtime persistence connection. | ||
The Runtime Dependencies panel is for adding dependent libraries to the current project. While you can independently add and remove libraries from the project, this panel can bootstrap the project with a full set of libraries typically needed by a Spring application, including Spring libraries plus many other runtime libraries.
This panel lets you add project dependencies in three ways:
Copy libraries to a project folder (lib), and add libraries to build path (Benefit: more portable projects because projects aren't reliant on MyEclipse for Spring plugins)
Use Eclipse classpath containers, and add classpath containers to build path (Benefit: smaller projects because libs are included)
Update Maven POM files (Benefit: Maven manages dependencies)
The libraries to add to the current project can be enabled or disabled by library group or library. The library groups can be expanded to see the specific libraries and versions.
Table 3.13. Add Spring Runtime Dependencies - Runtime Dependencies Panel
| Options | Description | ||
|---|---|---|---|
| Use Eclipse classpath containers instead of copying libraries into the project |
For standard Eclipse projects (non-Maven) the dependent Java libraries can be added to project using classpath containers (default) or copying the Java libraries into the specified project folder. For Maven-based projects the dependent Java libraries are added as dependencies to the Maven POM file. |
||
| Library folder | The project folder where libraries should be copied into | ||
| Library groups / libraries |
The set of library groups and libraries that can be added to the current project. The checked groups/libraries will be added as dependencies to the current project. |
||
| Spring 2.5 / Spring 3.0 |
Select the version of Spring that you want to use. |
||
The Scaffolding options panel is for specifying whether pre-existing artifacts should be updated. If these artifacts already exist in the project, you have the option of specifying whether they should be overwritten or skipped.
The Select Target Folders panel is for specifying where source code, configuration files and dependent libraries should be installed.
Table 3.14. Scaffold Spring CRUD Application - Select Target FoldersPanel
| Details | Description | ||
|---|---|---|---|
| Source Folder | Specify the destination folder for generated Java code. | ||
| Resources Folder | Specify the destination folder for generated configuration files. | ||
| Web Content Folder | Specify the destination folder for generated web layer resources. | ||
| Use Eclipse classpath containers instead of copying libraries into project | Unselected by default. (For Maven-based projects, this option is disabled because for Maven-based projects dependencies are always added to the Maven POM file.) | ||
| Library Folder | The folder where dependent libraries should be copied. This option is disabled when using Eclipse classpath containers or Maven-based projects. | ||
| Spring Version | What version of Spring libraries should be added to project. | ||
| Add Spring Nature | Add Spring Nature to current project to enable viewing/editing Spring configurations using Spring Elements node. When applied, all generated Spring context files will be preconfigured with Spring Elements. | ||
The Select DB Connection panel is for specifying the database connection for accessing the database tables that should be reverse-engineered for scaffolding.
Table 3.15. Scaffold Spring CRUD Application - Select DB Connection Panel
| Details | Description | ||
|---|---|---|---|
| DB Connection | Lists all the current MyEclipse DB connections. Select the connection for accessing DB tables. | ||
The Select Database Tables panel is for selecting the database tables that should be reverse-engineered for scaffolding.
Select the schema where the desired database tables are located. The dialects will be defaulted based on the data connection properties, but they can be overridden.
Select the tables, including associated tables, that should be used for scaffolding.
Table 3.16. Scaffold Spring CRUD Application - Select Database Tables Panel
| Details | Description | ||
|---|---|---|---|
| Schema | Used to select the schema that has the tables for scaffolding from. The schema dropdown will list all schemas from the selected database connection. | ||
| Dialect | The Hibernate dialect to use the specified database. This value will be defaulted according to the selected database connection. | ||
| MetaData Dialect | |||
| Tables | The list of tables that were found in the selected schema. This list will be empty until a schema is selected. | ||
| Scaffolding | The list of tables that should be used for scaffolding. One or more tables can be added from the Tables list to the scaffolding list. | ||
The Database Scaffolding Options panel is for specifying parent objects and customizing object names.
The table lists the objects that are going to be generated. When scaffolding associations (i.e one-to-many) the generated application will enable associated objects to be managed as part of a parent object. Please check the objects that should be treated as parent objects. Unchecked objects will be treated as associated objects.
The object name is automatically derived from the table name, but you can override the object name by double-clicking on the name and specifying a new name.
Table 3.17. Scaffold Spring CRUD Application - Database Scaffolding Options Panel
| Details | Description | ||
|---|---|---|---|
| Java Object |
The derived name for the JAVA object. The JAVA object name is based on the table name. If table name doesn't follow JAVA class naming conventions and rules, the default name may be slightly altered to conform. The JAVA object names can also be customized by double-clicking on the name and entering a new name. You must specify at least one Java object as the parent object, which is the principle artifact(s) used for scaffolding user interfaces. |
||
| Table | This is the table that the Java Object is being derived from. READ-ONLY | ||
The Add Spring Runtime Dependencies... Wizard is used to add dependent libraries to an Eclipse project. There are three steps to the wizard.
Add Spring Runtime Dependencies >> Intro >> Runtime Dependencies >> Summary
The Runtime Dependencies panel is for adding dependent libraries to the current project. While you can independently add and remove libraries from the project, this panel can bootstrap the project with a full set of libraries typically needed by a Spring application, including Spring libraries plus many other runtime libraries.
This panel lets you add project dependencies in three ways:
Copy libraries to a project folder (lib), and add libraries to build path (Benefit: more portable projects because projects aren't reliant on MyEclipse for Spring plugins)
Use Eclipse classpath containers, and add classpath containers to build path (Benefit: smaller projects because libs are included)
Update Maven POM files (Benefit: Maven manages dependencies)
The libraries to add to the current project can be enabled or disabled by library group or library. The library groups can be expanded to see the specific libraries and versions.
Table 3.18. Add Spring Runtime Dependencies - Runtime Dependencies Panel
| Options | Description | ||
|---|---|---|---|
| Use Eclipse classpath containers instead of copying libraries into the project |
For standard Eclipse projects (non-Maven) the dependent Java libraries can be added to project using classpath containers (default) or copying the Java libraries into the specified project folder. For Maven-based projects the dependent Java libraries are added as dependencies to the Maven POM file. |
||
| Library folder | The project folder where libraries should be copied into | ||
| Library groups / libraries |
The set of library groups and libraries that can be added to the current project. The checked groups/libraries will be added as dependencies to the current project. |
||
| Spring 2.5 / Spring 3.0 |
Select the version of Spring that you want to use. |
||
Security is an important part of a web application, and Spring Security provides a set of security services that integrate with Spring-based applications. The Scaffold Spring Security wizard will configure the application for Spring Security and secure services and URLs:
Database - using a DB security realm configured to use a scaffolded set of database tables (users and authorities)
LDAP - using LDAP security realm
In-Memory - using an in-memory security realm
Here's the flow of the wizard based on the chosen security option.
Database
Scaffold Spring Security >> Overview >> Security Options [Database] >> Select Package >> Select DB Connection >> Secure Services >> Secure URLs >> Configure Views >> Summary
LDAP
Scaffold Spring Security >> Overview >> Security Options [LDAP] >> LDAP Configuration >> Secure Services >> Secure URLs >> Configure Views >> Summary
In-Memory
Scaffold Spring Security >> Overview >> Security Options [In Memory] >> Secure Services >> Secure URLs >> Configure Views >> Summary
The Overview panel will provides an introduction to the Scaffold Spring Security wizard.
The Security Options panel prompts you for the security type and password encoding.
Table 3.19. Scaffold Spring Security - Select Options Panel
| Details | Description | ||
|---|---|---|---|
| Security Type |
The list of authentication providers that can be scaffolded:
|
||
| Password Encoding |
The list of password encoding options:
|
||
The Secure Services panel will scan your project for services (@Service and @Repository components) that can be secured. By default all services will be secured (checked) and configured with IS_AUTHENTICATED_REMEMBERED access. The wizard lets you unsecure the service and edit the access.
Table 3.20. Scaffold Spring Security - Secure Services Panel
| Details | Description | ||
|---|---|---|---|
| Service | The application service that was found by the wizard by scanning the current project. | ||
| Secured | Specifies whether the service is to be secured. This option is enabled by default for all scanned services, however it can be disabled. | ||
| Access | The access attributes for the service. This could be authentication attributes (i.e. IS_AUTHENTICATED_FULLY, IS_AUTHENTICATED_REMEMBERED, or IS_AUTHENTICATED_ANONYMOUSLY) or role names (i.e. ROLE_USER or ROLE_ADMIN). | ||
The Secure URLs panel prompts you for the URLs that should be secured. Unlike the Secure Services panel, the wizard will only secure one URL (/secure/*) by default, and you must specify (add and remove) other URLs based on your security requirements.
Table 3.21. Scaffold Spring Security - Secure URLs Panel
| Details | Description | ||
|---|---|---|---|
| URL Pattern | The URL to be secured. | ||
| Secured | Specifies whether the service is to be secured. This option is enabled by default for all scanned services, however it can be disabled. | ||
| Access | The access attributes for the URL. This could be authentication attributes (i.e. IS_AUTHENTICATED_FULLY, IS_AUTHENTICATED_REMEMBERED, or IS_AUTHENTICATED_ANONYMOUSLY) or role names (i.e. ROLE_USER or ROLE_ADMIN). | ||
The Configure Views panel ....
Table 3.22. Scaffold Spring Security - Configure Views Panel
| Details | Description | ||
|---|---|---|---|
| Login view | The URL that should be used to render the login page | ||
| Login success view | A user will be taken to this URL after logging in, provided they were not asked to login while attempting to access a secured resource, when they will be taken to the originally requested URL. | ||
| Always go to the login success view after authenticating | If checked, the user will always be directed to the login success view URL, regardless of how they arrived at the login page. | ||
| Login failure view | Defines the URL the browser will be redirected to on login failure. | ||
| Logout success view | The destination URL which the user will be taken to after logging out. Defaults to "/". | ||
| Access denied view | The destination URL which the user will be taken to if they don't have priviledges for the secured resource. | ||
The Select Target Folders panel prompts you for the directory where code should be generated to.
When using the database security option, this wizard will generate to JPA entities for you. The User JPA entity and UserDAO data access object is for storing user credentials. The Authorities JPA entity and AuthoritiesDAO data access object is for storing authorization data. The Select Package panel prompts you for the Java package for generated code.
Table 3.23. Scaffold Spring Security - Select Package Panel
| Details | Description | ||
|---|---|---|---|
| Package | The package for User/Authorities JPA entities and DAO. | ||
The Select DB Connection panel prompts you for the database connection profile that should be used for the persistence configuration of the User and Authorities DAOs.
Table 3.24. Scaffold Spring Security - Select DB Connection Panel
| Details | Description | ||
|---|---|---|---|
| DB Connection | Lists all of the available MyEclipse DB connections. Select the DB connection that should be used for the persistence configuration of the DAOs. | ||
The LDAP Configuration panel prompts you for the LDAP information.
The Add Spring Runtime Dependencies... Wizard is used to add dependent libraries to an Eclipse project. There are three steps to the wizard.
Add Spring Runtime Dependencies >> Intro >> Runtime Dependencies >> Summary
The Runtime Dependencies panel is for adding dependent libraries to the current project. While you can independently add and remove libraries from the project, this panel can bootstrap the project with a full set of libraries typically needed by a Spring application, including Spring libraries plus many other runtime libraries.
This panel lets you add project dependencies in three ways:
Copy libraries to a project folder (lib), and add libraries to build path (Benefit: more portable projects because projects aren't reliant on MyEclipse for Spring plugins)
Use Eclipse classpath containers, and add classpath containers to build path (Benefit: smaller projects because libs are included)
Update Maven POM files (Benefit: Maven manages dependencies)
The libraries to add to the current project can be enabled or disabled by library group or library. The library groups can be expanded to see the specific libraries and versions.
Table 3.26. Add Spring Runtime Dependencies - Runtime Dependencies Panel
| Options | Description | ||
|---|---|---|---|
| Use Eclipse classpath containers instead of copying libraries into the project |
For standard Eclipse projects (non-Maven) the dependent Java libraries can be added to project using classpath containers (default) or copying the Java libraries into the specified project folder. For Maven-based projects the dependent Java libraries are added as dependencies to the Maven POM file. |
||
| Library folder | The project folder where libraries should be copied into | ||
| Library groups / libraries |
The set of library groups and libraries that can be added to the current project. The checked groups/libraries will be added as dependencies to the current project. |
||
| Spring 2.5 / Spring 3.0 |
Select the version of Spring that you want to use. |
||
The Enable Spring DSL wizard is used to configure a project to use the Spring DSL.
By default this wizard is setup with conventional defaults which enable all options. When clicking on Finish from the Setup panel, all the default configuration options will be applied to the current project. In order to customize the configuration, there are seven optional steps to the wizard.
Add Spring Code Generation Capabilities >> Setup >> Web Layer Generation >> Service Layer Generation >> Domain Layer Generation >> Data Access Layer Generation >> Runtime Dependencies >> Summary
The Setup panel is for specifying whether the Spring Nature should be applied to the project.
Table 3.27. Add Spring Code Generation Capabilities - Setup Panel
| Option | Description | ||
|---|---|---|---|
| Add the MyEclipse Spring Nature | Add Spring Nature to current project to enable viewing/editing Spring configurations using Spring Elements node. When applied, all generated Spring context files will be preconfigured with Spring Elements. | ||
The Web Layer Generation panel is used for enabling and configuring code generation for the web layer of a Spring application, including controllers (@Controller), JUnit tests, and web layer Spring context files.
If enabled, this panel lets you specify the project and folders to generate to. While you will typically want to generate to the same project where the code generation metadata (Spring DSL) is stored, in some cases you may want to generate to a different project. For example, you may want to keep all your metadata in one project and have all code and configuration files generated to another project. Alternatively you may want to generate each layer to a separate project. In either case you have full control over the target project and folders.
Table 3.28. Add Spring Code Generation Capabilities - Web Layer Generation Panel
| Option | Description | ||
|---|---|---|---|
| Enable web layer code generation | This enables generation of web layer artifacts from code generation metadata. If disabled, any current or new web layer metadata will be ignored from a code generation standpoint. Web layer code generation can always be turned on/off or customized using the Code Generation panel of the Spring DSL Editor. | ||
| Target Project | The target project is the destination project for web layer code generation. While you will typically want to generate to the same project where the code generation metadata is stored (Generate to this project), in some cases you may want to generate to a different project (Generate to another Eclipse project). | ||
| Target Project Configuration |
Specify the destination folder for generated Java code (Source folder), configuration files (Resources folder) and web content (Content). If the specified folders aren't already configured as source folders, the Source and Resource folders are automatically added as source folders (see Java Build Path). For standard Eclipse web projects (non-Maven):
For Maven-based projects:
|
||
The Service Layer Generation panel is used for enabling and configuring code generation for the service layer of a Spring application, including services (@Service), service interfaces, JAX-WS web services, direct web remoting (DWR) services, JUnit tests, and service layer Spring context files.
If enabled, this panel lets you specify the project and folders to generate to. While you will typically want to generate to the same project where the code generation metadata (Spring DSL) is stored, in some cases you may want to generate to a different project. For example, you may want to keep all your metadata in one project and have all code and configuration files generated to another project. Alternatively you may want to generate each layer to a separate project. In either case you have full control over the target project and folders.
Table 3.29. Add Spring Code Generation Capabilities - Service Layer Generation Panel
| Option | Description | ||
|---|---|---|---|
| Enable service layer code generation | This enables generation of service layer artifacts from code generation metadata. If disabled, any current or new service layer metadata will be ignored from a code generation standpoint. Service layer code generation can always be turned on/off or customized using the Code Generation panel of the Project Editor. | ||
| Target Project | The target project is the destination project for service layer code generation. While you will typically want to generate to the same project where the code generation metadata is stored (Generate to this project), in some cases you may want to generate to a different project (Generate to another Eclipse project). | ||
| Target Project Configuration |
Specify the destination folder for generated Java code (Source folder) and configuration files (Resources folder). If the specified folders aren't already configured as source folders, the Source and Resource folders are automatically added as source folders (see Java Build Path). For standard Eclipse web projects (non-Maven):
For Maven-based projects:
|
||
The Domain Layer Generation panel is used for enabling and configuring code generation for the domain layer of a Spring application, including POJOs, primary key classes, bean info classes, JPA Entities (@Entity), Spring Components (@Component), JUnit tests, and domain layer Spring context files.
If enabled, this panel lets you specify the project and folders to generate to. While you will typically want to generate to the same project where the code generation metadata (Spring DSL) is stored, in some cases you may want to generate to a different project. For example, you may want to keep all your metadata in one project and have all code and configuration files generated to another project. Alternatively you may want to generate each layer to a separate project. In either case you have full control over the target project and folders.
Table 3.30. Add Spring Code Generation Capabilities - Domain Layer Generation Panel
| Option | Description | ||
|---|---|---|---|
| Enable domain layer code generation | This enables generation of domain layer artifacts from code generation metadata. If disabled, any current or new domain layer metadata will be ignored from a code generation standpoint. domain layer code generation can always be turned on/off or customized using the Code Generation panel of the Project Editor. | ||
| Target Project | The target project is the destination project for domain layer code generation. While you will typically want to generate to the same project where the code generation metadata is stored (Generate to this project), in some cases you may want to generate to a different project (Generate to another Eclipse project). | ||
| Target Project Configuration |
Specify the destination folder for generated Java code (Source folder) and configuration files (Resources folder). If the specified folders aren't already configured as source folders, the Source and Resource folders are automatically added as source folders (see Java Build Path). For standard Eclipse web projects (non-Maven):
For Maven-based projects:
|
||
The Data Access Layer Generation panel is used for enabling and configuring code generation for the DAO layer of a Spring application, including Spring repositories (@Repositiry), JUnit tests, and DAO layer Spring context files.
If enabled, this panel lets you specify the project and folders to generate to. While you will typically want to generate to the same project where the code generation metadata (Spring DSL) is stored, in some cases you may want to generate to a different project. For example, you may want to keep all your metadata in one project and have all code and configuration files generated to another project. Alternatively you may want to generate each layer to a separate project. In either case you have full control over the target project and folders.
Table 3.31. Add Spring Code Generation Capabilities - Web Layer Generation Panel
| Option | Description | ||
|---|---|---|---|
| Enable data access layer code generation | This enables generation of DAO layer artifacts from code generation metadata. If disabled, any current or new DAO layer metadata will be ignored from a code generation standpoint. DAO layer code generation can always be turned on/off or customized using the Code Generation panel of the Project Editor. | ||
| Target Project | The target project is the destination project for DAO layer code generation. While you will typically want to generate to the same project where the code generation metadata is stored (Generate to this project), in some cases you may want to generate to a different project (Generate to another Eclipse project). | ||
| Target Project Configuration |
Specify the destination folder for generated Java code (Source folder) and configuration files (Resources folder). If the specified folders aren't already configured as source folders, the Source and Resource folders are automatically added as source folders (see Java Build Path). For standard Eclipse web projects (non-Maven):
For Maven-based projects:
|
||
The Runtime Dependencies panel is for adding dependent libraries to the current project. While you can independently add and remove libraries from the project, this panel can bootstrap the project with a full set of libraries typically needed by a Spring application, including Spring libraries plus many other runtime libraries.
This panel lets you add project dependencies in three ways:
Copy libraries to a project folder (lib), and add libraries to build path (Benefit: more portable projects because projects aren't reliant on MyEclipse for Spring plugins)
Use Eclipse classpath containers, and add classpath containers to build path (Benefit: smaller projects because libs are included)
Update Maven POM files (Benefit: Maven manages dependencies)
The libraries to add to the current project can be enabled or disabled by library group or library. The library groups can be expanded to see the specific libraries and versions.
Table 3.32. Add Spring Code Generation Capabilities - Runtime Dependencies Panel
| Options | Description | ||
|---|---|---|---|
| Use Eclipse classpath containers instead of copying libraries into the project |
For standard Eclipse projects (non-Maven) the dependent Java libraries can be added to project using classpath containers (default) or copying the Java libraries into the specified project folder. For Maven-based projects the dependent Java libraries are added as dependencies to the Maven POM file. |
||
| Library folder | The project folder where libraries should be copied into | ||
| Library groups / libraries |
The set of library groups and libraries that can be added to the current project. The checked groups/libraries will be added as dependencies to the current project. |
||
| Spring 2.5 / Spring 3.0 |
Select the version of Spring that you want to use. |
||
Table of Contents
The Spring DSL is only applicable to projects that have been enabled with Spring code generation capabilities using the Enable Spring DSL wizard.
The following sections describe the Project wizards and editors.
The Project Editor is accessed by double-clicking on the Spring DSL node in the project, and it's comprised of the Overview Tab, the Web Application Tab, the Enterprise Configuration Tab, the Spring Configuration Tab, the Category Mapping Tab, and the Code Generation Tab. The follow sections describe each tab in detail.
The Overview tab allows a user to describe the project and link to other tabs in the Project Editor. Refer to the following figure and table for details on this tab.
Table 4.1. Project Editor - Overview Tab
| Details | Description | ||
|---|---|---|---|
| Name | Identifies the name of the Project. | ||
| Description | Provide a meaningful description of the Project. | ||
Use the Category Mapping tab to reconfigure the target projects for each artifact category. Each Spring DSL artifact is associated with an artifact category, and the artifact category can be individually configured to generate to a particular Eclipse project.
The Category Mapping tab is also used to disable automated updates to project dependencies. For a Maven-based project this option will prevent MyEclipse for Spring from automatically updating the Maven pom file (pom.xml). For an Eclipse-based project this option will prevent MyEclipse for Spring from automatically updating your classpath (build path). If disabled, you are responsible from manually maintaining the project classpath.
Table 4.2. Project Editor - Category Mapping Tab
| Details | Description | ||
|---|---|---|---|
| Artifact Categories | Used to configure the destination project for each available application layer. | ||
| Category | The application layer name. This column is read-only. | ||
| Project |
The specific Eclipse project that the application layer should be generated to. This setting is originally set by the Enable Spring DSL wizard when specifying the target project for web, service,domain and DAO layers. It can be reconfigured here or by re-running wizard. |
||
| Id |
The id used to reference the category from the Code Generation tab. |
||
| Edit | Select an artifact category and click this button to invoke the Project picker. | ||
The Web Application tab is used to specify the default suffix that's used for operation URLs (for controllers) that are created using the New Operation Wizard.
Table 4.3. Project Editor - Web Application Tab
| Details | Description | ||
|---|---|---|---|
| Default URL Mapping Suffix | The suffix to be appended to the end of new URL mappings. | ||
The Enterprise Configuration tab of the Project Editor allows a user to configure the Spring Security settings for the project.
Table 4.4. Project Editor - Enterprise configuration Tab
| Details | Description | ||
|---|---|---|---|
| Secured URLS | This subsection allows a user to specify urls and set them as secured. | ||
| URL Pattern | Lists the URL patterns added. | ||
| Secured | Click this check box to secure the associated URL. | ||
| Add | Click this button to Add a new URL pattern. | ||
| Remove | Click this button to remove a selected URL from the URL Pattern list. | ||
| Up/Down | Click these buttons to change the order of the selected URL from the URL Pattern list. | ||
| Secured Resources | This subsection allows a user to specify urls and set them as secured. | ||
| Service | Displays the project's services available to secure. | ||
| Secured | Click this check box to secure the associated Service. | ||
| Data Access Object | Displays the project's data access objects available to secure. | ||
| Secured | Click this check box to secure the associated Data Access Object. | ||
| Configured Views | This subsection allows a user to select the views that will handle security functions. | ||
| Login View | Default page: /login.jsp | ||
| Login Failure View | Default page: t/login.jsp?login_error=1 | ||
| Login Success View | Default page: /success.jsp | ||
| Access Denied View | Default page: /accessDenied.jsp | ||
| Security Information Source | This subsection allows a user to configure the security information source as either Database or LDAP. | ||
| Database | Select this radio button to configure database settings. | ||
| LDAP | Select this radio button to configure LDAP settings. | ||
The Spring Configuration tab allows a user to configure the mail server.
Table 4.5. Project Editor - Spring Configuration Tab
| Details | Description | ||
|---|---|---|---|
| Mail Server | Enter the mail server. By default this is not set. When the mail server is specified, a mail sender bean is emitted into service context file. | ||
The Code Generation tab is for configuring various project-level code generation options, including the collection type that should be use for persistent relationships and the default code generation options for the generated code.
Persistent Collection Type
Select the type of collection to use for persistent relationships.
Table 4.6. Project Editor - Code Generation Tab - Persistent Collection Type
| Details | Description | ||
|---|---|---|---|
| Ordered Set |
Interface Type: java.util.Set Implementation Type: java.util.LinkedHashSet |
||
| List |
Interface Type: java.util.List Implementation Type: java.util.ArrayList |
||
| Set |
Interface Type: java.util.Set Implementation Type: java.util.HashSet |
||
| Sorted Set |
Interface Type: java.util.SortedSet Implementation Type: java.util.TreeSet |
||
| Custom |
Interface Type: <pick the interface> Implementation Type: <pick an implementation of the interface> |
||
Code Generation
This section configures the default code generation settings for the entire project. From the Project Editor there's an entry for every artifact that is generated using MyEclipse for Spring. The settings can be overridden individually on an artifact by using the artifact's code generation tab, which will only contain entries for the artifacts generated resources.
Table 4.7. Project Editor - Code Generation Tab - Code Generation
| Details | Description | ||
|---|---|---|---|
| Generate | Specifies whether this resource should be generated. By default all resources are generated and regenerated, but you can disable this at the project level by unchecking the checkbox for the resources that should no longer be generated. | ||
| Name | A friendly name for the resource that is represented by the configuration entry. | ||
| Filename | The name of the file that should be generated for the resource. You can reference the artifact name by using the ${model.name} expression in the filename. | ||
| Package | The package name that should be used for the generated resource. This setting only applies to resources that get generated into JAVA classes. You can reference the model package that the artifact was created in by using the ${model.package} expression in the package name, | ||
| Path | The directory where the resource should be generated to. You can reference the category mapping (from the Category Mapping tab) location in the path by using the ${category} expression. You can also reference the model package that the artifact was created in by using the ${model.package} expression in the path. To generate the resource to multiple locations, you can specify multiple paths (comma delimited). | ||
| Category | Associates the artifact with an application layer. This is primarily related to the category mappings, where you can change the project that the resource gets generated into. | ||
Here's a list of available code generation tokens that can be used for configuring code generation options.
Table 4.8. Code Generation Tokens
| Token | Description | ||
|---|---|---|---|
| ${model.name} | References the name given to the artifact in the Spring DSL. | ||
| ${parent.name] | References the name of the parent artifact for artifacts that have a parent artifact (i.e. Controller/Operation and Service/Operation) | ||
| ${model.package} | References the model package that contains the artifact in the Spring DSL. | ||
| ${category} | References the project path configured for the category (using Category Mapping tab). | ||
The Spring DSL Service is used for generating Spring @Service components and managing related source code and configuration files.
The Spring framework supports the @Service annotation which is a specialized stereotype for service layer components, and the Spring DSL Service artifact manages the creation of Spring services by:
providing a New Service wizard
providing a Service Editor for editing Spring Services that are managed by the Spring DSL
generating a Spring Service interface
generating a Spring Service implementation classes (annotated with @Service)
generating a JUnit test classes for service testing
[optional] enablement of the service for Java API for XML Web Services (JAX-WS - SOAP)
[optional] enablement of the service for Direct Web Remoting (Javascript/JSON)
While Services are often used in a Spring MVC application, Services are also applicable to just about any other presentation technology related Spring. If you are using a presentation technology other than Spring MVC (i.e. Spring Web Flow, JSF, Struts, GWT, AJAX, or Adobe Flex), they can all use Services for implementing the back-end business logic.
The New Service wizard is for creating new Spring Services for a development project.
New Service >> New Service
The New Service window is for specifying the name of the service and the model package that will contain the service.
Table 4.9. New Service Window
| Details | Description | ||
|---|---|---|---|
| Service Name | Enter the name of the new Service then click the Finish button. | ||
The Service Editor is used for configuring a Spring DSL Service, and it's comprised of the Overview Tab, the Variables Tab, the Spring Bean Configuration Tab, the JAXWS Tab, the DWR Tab, and the Code Generation Tab. The follow sections describe each tab in detail.
The Overview tab is used for providing a description of the Service, navigating to the files generated from the Service, and navigating to the other Service configuration tabs. Refer to the following figure and table for details on this tab.
Table 4.10. Service Editor - Overview tab
| Details | Description | ||
|---|---|---|---|
| Name | Identifies the name of the new Service. | ||
| Files | Click the Views link to display the generated source code. | ||
| Description | Provide a meaningful description of the Service. | ||
The Variables tab is used for defining Service variables. Service variables are available to all service operations. Refer to the following figure and table for details on this tab.
Table 4.11. Service Editor - Variables Tab
| Details | Description | ||
|---|---|---|---|
| Name | Identify the variable name. | ||
| Type | Select the data type of the variable. Click the desired row in the Type column to invoke the Select Type Picker. Select the desired data type and click OK. | ||
| Collection | Identify whether the parameter is a Collection. | ||
| Initial Value | Optional) a variable can be initialized with data by populating this column with the initial value. | ||
The Spring Bean Configuration tab is used to configure the scope and @Transaction annotations for the Service. Refer to the following figure and table for details on this tab.
Table 4.12. Service Editor - Spring Bean Configuration tab
| Details | Description | ||
|---|---|---|---|
| Enable Transaction | Specified whether the Spring transactional annotation should be emitted in this artifact's generated code | ||
| Read Only | Specifies a read-only transaction. | ||
| Timeout | Specifies how long a transaction may run before timing out. | ||
| Isolation | Specifies the degree of isolation this transaction has from the work of other transactions. | ||
| Propagation | Specifies the transaction propagation. | ||
| Rollback ClassNames | Specifies the exceptions that must cause a rollback. | ||
| No Rollback ClassNames | Specifies the exceptions that must not cause a rollback. | ||
| Scope | The scope for this bean. List of Available Scopes | ||
The Code Generation tab is for configuring the generation options for a Service. This tab shows you all the code artifacts that are generated and managed by the Spring DSL Service. Each entry in this table represents a code artifact that is generated for the Service. In addition to enabling and disabling code generation on an artifact-by-artifact basis, you can also customize the name of the artifact, the package used, and the location where the artifact is generated to.
Code Generation
The code generation settings can be specified at the project level, which will control the code generation settings for the entire project. The code generation settings can also be customized for each Service using the code generation tab from the respective Service.
For a description of the code generation settings available from the Service Editor, please refer the to Code Generation tab of the Project Editor.
The JAXWS Web Service tab is used for configuring the web service options for the Service. By default a Service isn't web service enabled. This tab is for enabling the Service to be published as a Web Service and for configuring the JAX-WS options for the Service and Operations. Refer to the following figure and tables for details on this tab.
When a Spring DSL Service is published as a web service, an endpoint interface is generated and annotated with the JAX-WS @WebService annotation. The following table describes the configuration options for the web service.
Table 4.13. Service Editor - JAXWS Web Service Tab - Web Service Details
| Details | Description | ||
|---|---|---|---|
| Publish Web Service | determines whether the Spring service will be published as a JAX-WS web service (@WebService) | ||
| Service Name | maps to the serviceName parameter of the @WebService annotation | ||
| Target Namespace | maps to the targetNamespace parameter of the @WebService annotation | ||
| Endpoint Interface | |||
| Port Name | maps to the portName and name parameters of the @WebService annotation | ||
| WSDL Location | the location of the WSDL representing the web service | ||
| Binding Type | maps to the binding type parameter of the @WebService annotation | ||
| Service Mode | maps to the service mode parameter of the @WebService annotation | ||
The handler chain and SOAP binding can be configured at the web service level. The @HandlerChain and @SOAPBinding annotations are generated into the endpoint interface.
Table 4.14. Service Editor - JAXWS Web Service Tab - Web Service - Advanced
| Details | Description | ||
|---|---|---|---|
| Handler Chain | determines whether this service will have a custom handler chain (@HandlerChain) | ||
| Name | the name of the handler chain ; maps to the name parameter of the @HandlerChain annotation | ||
| File | the name of the handler chain configuration file; maps to the file parameter of the @HandlerChain annotation | ||
| SOAP Binding | |||
| Style | maps to the style parameter of the @SOAPBinding annotation | ||
| Parameter Style | maps to the parameterStyle parameter of the @SOAPBinding annotation | ||
| Use | maps to the use parameter of the @SOAPBinding annotation | ||
Unless otherwise excluded, each operation in a Spring DSL Service is published as a web method. The operation in the endpoint interface is generated and annotated with the JAX-WS @WebMethod annotation. The following table describes the configuration options for the web method.
Table 4.15. Service Editor - JAXWS Web Service Tab - Method Details
| Details | Description | ||
|---|---|---|---|
| Exclude | determines whether the current operation will be excluded from the web service; by default all operations are included in a web service | ||
| Name | maps to the operationName parameter of the @WebMethod annotation; the name is defaulted to the name of the Spring DSL operation artifact | ||
| Action | maps to the action parameter of the @WebMethod annotation | ||
While the SOAP binding can be configured at the web service level, JAX-WS allows the SOAP binding to be customized at the web method level. The custom configurations in the following table will be reflected in the @SOAPBinding annotation generated for the web method. The request (@RequestWrapper) and response (@ResponseWrapper) of the web method can be also configured.
Table 4.16. Service Editor - JAXWS Web Service Tab - Method Details - Advanced
| Details | Description | ||
|---|---|---|---|
| SOAP Binding | |||
| Style | maps to the style parameter of the @SOAPBinding annotation | ||
| Parameter Style | maps to the parameterStyle parameter of the @SOAPBinding annotation | ||
| Use | maps to the use parameter of the @SOAPBinding annotation | ||
| Request Wrapper | |||
| Local Name | maps to the localName parameter of the @RequestWrapper annotation | ||
| Target Namespace | maps to the targetNamespace parameter of the @RequestWrapper annotation | ||
| Class Name | maps to the className parameter of the @RequestWrapper annotation | ||
| Response Wrapper | |||
| Local Name | maps to the localName parameter of the @RespondWrapper annotation | ||
| Target Namespace | maps to the targetNamespace parameter of the @ResponseWrapper annotation | ||
| Class Name | maps to the className parameter of the @ResponseWrapper annotation | ||
In JAX-WS the input parameters of a web method are configured using the @WebParam annotation. The following table lists the configuration options that will generated for the @WebParam annotation.
Table 4.17. Service Editor - JAXWS Web Service Tab - Parameter Details
| Details | Description | ||
|---|---|---|---|
| Input | maps to the style parameter of the @WebParam annotation | ||
| Name | maps to the name parameter of the @WebParam annotation | ||
| Part Name | maps to the partName parameter of the @WebParam annotation | ||
| Target Namespace | maps to the targetNamespace parameter of the @WebParam annotation | ||
| Mode | maps to the mode parameter of the @WebParam annotation | ||
| Header | maps to the header parameter of the @WebParam annotation | ||
The DWR tab is used for configuring the DWR (direct web remoting) options for the Service. By default a Service isn't DWR enabled. This tab is for enabling the Service to be published as a Javascript library (that uses JSON for data transferring) using DWR. Refer to the following figure and table for details on this tab.
The following table describes the configuration options for the DWR service.
Table 4.18. Service Editor - DWR Tab - DWR Service Details
| Details | Description | ||
|---|---|---|---|
| Publish | determines whether the service will be published as a DWR service | ||
| Javascript Name | the name of the dynamically generated javascript for the service | ||
Unless otherwise excluded, each operation in a Spring DSL Service is published as a javascript function. The following table describes the DWR configuration options for the operations.
Table 4.19. Service Editor - DWR Tab - DWR Method Details
| Details | Description | ||
|---|---|---|---|
| Exclude | determines whether the current operation will be excluded from DWR; by default all operations are included in a service that is published for DWR. | ||
| Method Name | the name of the dynamically generated javascript method; the name is defaulted to the name of the Spring DSL operation artifact | ||
DWR will automatically generates some pages that can assist in
developing with DWR. The DWR Service index page
lists all the classes known to DWR. It's useful for verifying which
Spring DSL services are or are not DWR enabled. The URL for the
accessing the index page is
http://server:port//context/dwr/index.html
The Flex tab is used for configuring the Adobe Flex options for the Service. By default a Service isn't Flex enabled. This tab is for enabling the Service to be published as a Flex remote service using Spring-Flex. Refer to the following figure and table for details on this tab.
The following table describes the configuration options for the Flex service.
Table 4.20. Service Editor - Flex Tab - Flex Service Details
| Details | Description | ||
|---|---|---|---|
| Publish | determines whether the service will be published as a Flex remote service | ||
| Destination Id | the channel name for the remote Flex service | ||
Unless otherwise excluded, each operation in a Spring DSL Service is published as a Flex remote function. The following table describes the Flex configuration options for the operations.
Table 4.21. Service Editor - Flex Tab - Flex Method Details
| Details | Description | ||
|---|---|---|---|
| Exclude | determines whether the current operation will be excluded from Flex; by default all operations are included in a service that is published for Flex. | ||
| Method Name | the name of the dynamically generated Flex remote method; the name is defaulted to the name of the Spring DSL operation artifact | ||
The Spring DSL Controller is used for generating annotation-based controllers for Spring MVC and managing related source code and configuration files.
The Spring DSL Controller supports the creation of Spring controllers by:
providing a New Controller wizard
providing a Controller Editor for editing Spring Controllers that are managed by the Spring DSL
generating a Spring Controller implementation classes (annotated with @Controller)
generating a JUnit test classes for controller testing
managing the association of URLs to request handlers
The New Web Controller wizard is for adding a controller to the application.
New Web Controller >> New Web Controller
The New Web Controller window is for specifying the name of the web controller and the model package that will contain the web controller.
Table 4.22. New Web Controller Window
| Details | Description | ||
|---|---|---|---|
| File Name | Enter the desired file name in the File Name text box and click the Finish button. | ||
The Web Controller Editor is comprised of the Overview Tab, the Spring MVC Tab, the Variables Tab, the Spring Configuration Tab, and the Code Generation Tab. The follow sections describe each tab in detail.
The Overview tab is used for providing a description of the Controller, navigating to the files generated from the Controller, and navigating to the other Controller configuration tabs. Refer to the following figure and table for details on this tab.
Table 4.23. Web Controller Editor - Overview Tab
| Details | Description | ||
|---|---|---|---|
| Name | Identifies the Web Controller name. | ||
| Files | Click the Views link to display the generated source code. | ||
| Description | Provide a meaningful description of the Web Controller. | ||
| Define URL Mappings | Click this link to jump to the URL Mapping tab. | ||
When Operations are added to a Controller, they are generated as Java methods in the controller. The Spring MVC framework provides a variety of annotations for specifying the behaviour of the Java methods and managing data binding, and the Sprint MVC tab assists in annotating the Java methods and configuring the annotations.
Here's a summary of the Spring MVC annotations:
Table 4.24. Spring MVC Annotations - Description
| Annotation | Description | ||
|---|---|---|---|
| @RequestMapping | See @RequestMapping | ||
| @RequestParam | See @RequestParam | ||
| @ModelAttribute |
See @ModelAttribute |
||
| @InitBinder | See @InitBinder | ||
An example might be helpful for understanding how the Spring MVC annotations are used with annotation-based controllers.
Example 4.1. Spring MVC Annotations - Example
@Scope("singleton")
@Controller("CustomerController")
public class CustomerController {
@RequestMapping(method = { RequestMethod.GET, RequestMethod.POST }, value = "/saveCustomer.html")
public String saveCustomer(@ModelAttribute(value = "customer") Customer customer
) {
//
}
@RequestMapping(method = { RequestMethod.GET, RequestMethod.POST }, value = "/selectCustomer.html")
public ModelAndView selectCustomer(@RequestParam(required = true, value = "customernumberKey")
Integer customernumberKey
) {
//
}
@InitBinder
public void initBinder(WebDataBinder binder, HttpServletRequest request)
{ // Register static property editors.
binder.registerCustomEditor(java.util.Calendar.class, new org.execution.databinding.CustomCalendarEditor());
}
@ModelAttribute(value = "cities")
public Set<Cities> getCities() {
//
}
}
| The @RequestMapping annotation specifies that saveCustomer() method should handle URL requests for "/saveCustomer.html". | |
| The @ModelAttribute annotation specifies that customer form data (command object) should be bound to the customer method parameter. The saveCustomer() method will have access to the form data by using the command method parameter. | |
| The @RequestParam annotation specifies that the request parameter "customernumberKey should be converted to an Integer and bound to the customernumberKey variable. | |
| The @InitBinder annotation specifies the method that should be used by the Spring MVC framework to register any custom data binding converters for the controller. | |
| The @ModelAttribute annotation specifies that the getCities() method should be run prior to any request handler in the controller. Any class variables set by this method will be available to the request handlers. The method output will be also available as model data in any views (JSP) under the specified key ("cities"). |
The Spring MVC panel helps configure the Spring MVC annotations for the methods and method parameters in a controller. When clicking on the controller, the controller properties will be displayed for editing. When expanding the controller and clicking on an operation, the operation properties will be displayed for editing.
Table 4.25. Web Controller Editor - Spring MVC Tab (Controller)
| Parameter | Description | |
|---|---|---|
| Controller / Methods |
This table shows the controller and it's associated methods. Clicking on the controller will display the annotation configuration panel for the controller. Clicking on a controller method will display the annotation configuration panel for the controller method. |
|
| Request Mapping | Configures the controller to handle requests for the given URL. Furthermore you can configure the request mapping for GET, POST, OPTIONS, PUT and DELETE. | |
| Operation Request Mappings |
[READ ONLY] This table shows all the operations that are configured as request mappings. It shows the operation name and configured URL. The Launch link enables the immediate launch of the specified URL in the default Eclipse browser. |
|
Table 4.26. Web Controller Editor - Spring MVC Tab (Operation)
| Parameter | Description | |
|---|---|---|
| Operation Details |
Enables the configuration of the operation as either a request handler (@RequestMapping), model attribute (@ModelAttribute) or init binder (@InitBinder). A given operation can only be either a request handler, model attribute or init binder method. |
|
| Request Mapping |
Configures the operation to handle requests for the given URL. Furthermore you can configure the request mapping for GET, POST, OPTIONS, PUT and DELETE. The request mapping table will show all operation parameters and enables the configuration of each parameter. The Mapped As column is for configuring whether the parameter is a Model Attribute, Request Parameter, or Unmapped. The Mapped Name can be configured. The Required column is for specifying whether the parameter is required. For new operations the mapped name is defaulted to the parameter name, and the Mapped As is determined by the parameter type. All parameters are considered to be required. |
|
| Model Attribute |
Configures the operation to be a @ModelAttribute using the given name. |
|
| InitBinder |
Configures the operation to be an @InitBinder. Optionally you can specify a list of form parameters that should use the specific init binder. |
|
The Variables tab is used for defining Controller variables. Controller variables are available to all controller operations. Refer to the following figure and table for details on this tab.
Table 4.27. Web Controller Editor - Variables Tab
| Details | Description | ||
|---|---|---|---|
| Name | Identify the variable name. | ||
| Type | Select the data type of the variable. Click the desired row in the Type column to invoke the Select Type Picker. Select the desired data type and click OK. | ||
| Collection | Identify whether the variable is a Collection. | ||
| Initial Value | (Optional) a variable can be initialized with data by populating this column with the initial value. | ||
| On Request |
Identify whether the variable should be annotated with the Spring @ModelAttribute.
|
||
The Spring Bean Configuration tab is used to configure the @Scope and @Transaction annotations for the Controller. Refer to the following figure and table for details on this tab.
Table 4.28. Controller Editor - Spring Bean Configuration tab
| Details | Description | ||
|---|---|---|---|
| Enable Transaction | Specified whether the Spring transactional annotation should be emitted in this artifact's generated code | ||
| Read Only | Specifies a read-only transaction. | ||
| Timeout | Specifies how long a transaction may run before timing out. | ||
| Isolation | Specifies the degree of isolation this transaction has from the work of other transactions. | ||
| Propagation | Specifies the transaction propagation. | ||
| Rollback ClassNames | Specifies the exceptions that must cause a rollback. | ||
| No Rollback ClassNames | Specifies the exceptions that must not cause a rollback. | ||
| Scope | The scope for this bean. List of Available Scopes | ||
The Code Generation tab is for configuring the generation options for a Controller. This tab shows you all the code artifacts that are generated and managed by the Spring DSL Controller. Each entry in this table represents a code artifact that is generated for the Controller. In addition to enabling and disabling code generation on an artifact-by-artifact basis, you can also customize the name of the artifact, the package used, and the location where the artifact is generated to.
Code Generation
The code generation settings can be specified at the project level, which will control the code generation settings for the entire project. The code generation settings can also be customized for each artifact using the code generation tab from the respective editor for the artifact.
For a description of the code generation settings available from the Service Editor, please refer the to Code Generation tab of the Project Editor.
The Spring DSL Component is used for generating Spring @Components and managing related source code and configuration files.
The Spring DSL Component supports the creation of Spring @Components by:
providing a New Component wizard
providing a Component Editor for editing Spring Controllers that are managed by the Spring DSL
generating a Spring Component implementation classes (annotated with @Component)
generating a JUnit test classes for component testing
The New Component wizard is for adding a component to a project.
New Component >> New Component
The New Component window is for specifying the name of the component and the model package that will contain the component.
Table 4.29. New Component Window
| Details | Description | ||
|---|---|---|---|
| Component Name | Enter the desired name for the Component then click the Finish button. | ||
The Component Editor is comprised of the Overview Tab, the Variables Tab, the Code Generation Tab, and the Spring Bean Configuration tab. The follow sections describe each tab in detail.
The Overview tab is used for providing a description of the Component, navigating to the files generated from the Component, and navigating to the other Component configuration tabs. Refer to the following figure and table for details on this tab.
Table 4.30. Component Editor - Overview Tab
| Details | Description | ||
|---|---|---|---|
| Name | Identifies the name of the Component. | ||
| Files | Click the Views link to display the generated source code. | ||
| Description | Provide a meaningful description of the Component. | ||
| Define Variables | click this link to jump to the Variables tab. | ||
| Define Constants | click this link to jump to the Constants tab. | ||
| Scope | Define the scope of the model. Valid options are Session or Request. | ||
The Variables tab is used for defining Component variables. Component variables are available to all component operations. Refer to the following figure and table for details on this tab.
Table 4.31. Component Editor - Variable Tab
| Details | Description | ||
|---|---|---|---|
| Name | Identify the variable name. | ||
| Type | Select the data type of the variable. Click the desired row in the Type column to invoke the Select Type picker. Select the desired data type and click OK | ||
| Initial Value | (Optional) a variable can be initialized with data by populating this column with the initial value. | ||
The Code Generation tab is for configuring the generation options for a Component. This tab shows you all the code artifacts that are generated and managed by the Spring DSL Component. Each entry in this table represents a code artifact that is generated for the Component. In addition to enabling and disabling code generation on an artifact-by-artifact basis, you can also customize the name of the artifact, the package used, and the location where the artifact is generated to.
Code Generation
The code generation settings can be specified at the project level, which will control the code generation settings for the entire project. The code generation settings can also be customized for each artifact using the code generation tab from the respective editor for the artifact.
For a description of the code generation settings available from the Service Editor, please refer the to Code Generation tab of the Project Editor.
The Spring Bean Configuration tab is used to configure the scope and @Transaction annotations for the Component. Refer to the following figure and table for details on this tab.
Table 4.32. Component Editor - Spring Bean Configuration tab
| Details | Description | ||
|---|---|---|---|
| Enable Transaction | Specified whether the Spring transactional annotation should be emitted in this artifact's generated code | ||
| Read Only | Specifies a read-only transaction. | ||
| Timeout | Specifies how long a transaction may run before timing out. | ||
| Isolation | Specifies the degree of isolation this transaction has from the work of other transactions. | ||
| Propagation | Specifies the transaction propagation. | ||
| Rollback ClassNames | Specifies the exceptions that must cause a rollback. | ||
| No Rollback ClassNames | Specifies the exceptions that must not cause a rollback. | ||
| Scope | The scope for this bean. List of Available Scopes | ||
An Operation is a Spring DSL artifact that defines methods for Services, Controllers and Components. Operations are visual representations of Java methods, and they are shown as children artifacts to the respective Service, Controller or Component in the Spring DSL explorer. Operations use inputs and outputs for exchanging data, and they are generated as methods directly into the respective class.
The following sections describe the Operation wizards and editors.
The New Operation wizard is for adding a new operation to either a controller, service or component. By default all operations that are created with the New Operation wizard will be considered a public API operation, and this can be customized from the Overview tab of the Operation editor.
New Operation >> New Operation >> Operation Options
The New Operation window is for specifying the name of the operation and the controller, component or service that will contain the operation.
Table 4.33. New Operation Window
| Details | Description | ||
|---|---|---|---|
| Operation Name | Enter the name of the new Operation then click the Finish button. | ||
| Description | Enter a meaningful description for this Operation then click the Finish button. | ||
If you are creating a new operation in a controller, then the New Operation wizard will automatically create URL mapping (@RequestMapping) for the operation. Request mappings can also be managed using the Spring MVC tab.
Table 4.34. Operation Options Window
| Details | Description | ||
|---|---|---|---|
| Create a URL Mapping | For Controller Operations Only: Enable this checkbox to create a URL Mapping for this operation. URL Mappings can also be added at a later time using Spring MVC tab. | ||
| URL | For Controller Operations Only: When "Create a URL Mapping" is enabled, the URL is for specifying the URL for the URL Mapping. A default URL mapping is derived from the controller name and operation name, but the URL is completely configurable by the developer. | ||
The Operation Editor is comprised of the Overview Tab, the Input/Outputs Tab, the Spring Bean Configuration Tab, and the Code Generation Tab. The follow sections describe each tab in detail.
The Overview tab is used for providing a description of the Operation, navigating to the files generated from the Operation, navigating to the other configuration tabs, and defining operation exceptions. Refer to the following figure and table for details on this tab.
Table 4.35. Operation Editor - Overview Tab
| Details | Description | ||
|---|---|---|---|
| Name | Identifies the name of the new Operation. | ||
| Files | Click the Views link to display the generated source code. | ||
| Description | Enter a meaningful description for this Operation. | ||
| Exceptions | In the Exception tab, the user can configure Exceptions thrown by the Operation. | ||
| Visibility | Specifies the visibility (public, private or protected) of the operation. | ||
| API | Specifies whether the operation should be considered part of the the public API of the service, controller, or component. You may not want some operations (i.e. getters/setters) to be reflected in secondary generation artifacts (i.e. interfaces, unit tests, web services, etc...), and the API setting let's specify which operations should be considered public. Public operations will be reflected in secondary artifacts. | ||
The Inputs/Outputs tab defines the input and output parameters of a particular operation. When this operation is invoked, the consumer (client) or the operation is required to map variables to the input and output parameters. Refer to the following figure and table for details on this tab.
Table 4.36. Operation Editor - Inputs/Outputs Tab
| Details | Description | ||
|---|---|---|---|
| Inputs | Define the Inputs to this Operation. | ||
| Name | Identify the input parameter name. | ||
| Type | Select the data type of the parameter. To select a Domain Object as the variable type, choose the Domain Object option from the Type drop-down menu. Select the desired data type from the data type picker and click OK. | ||
| Collection | Identify whether the parameter is a Collection | ||
| Add | Click this button to add an input variable. The default is Input_1, incrementing as additional variables are added until they are renamed. | ||
| Outputs | Define the Outputs to this Operation. | ||
| Name | Identify the input parameter name. | ||
| Type | Displays the data type of the input variable selected in the Assignment column. | ||
| Assignment | Select the Operation variable to assign to the output variable. Any variable from the variable list on the Variables sub-tab may be mapped to an output variable. | ||
| Add | Click this button to add an output variable. The default is Output_1, incrementing as additional variables are added until they are renamed. | ||
The Spring Bean Configuration tab is used to configure the scope and @Transaction annotations for the Operation. Refer to the following figure and table for details on this tab.
Table 4.37. Operation Editor - Spring Bean Configuration tab
| Details | Description | ||
|---|---|---|---|
| Enable Transaction | Specified whether the Spring transactional annotation should be emitted in this artifact's generated code | ||
| Read Only | Specifies a read-only transaction. | ||
| Timeout | Specifies how long a transaction may run before timing out. | ||
| Isolation | Specifies the degree of isolation this transaction has from the work of other transactions. | ||
| Propagation | Specifies the transaction propagation. | ||
| Rollback ClassNames | Specifies the exceptions that must cause a rollback. | ||
| No Rollback ClassNames | Specifies the exceptions that must not cause a rollback. | ||
| Scope | The scope for this bean. List of Available Scopes | ||
The Code Generation tab is for configuring the generation options for an Operation. The implementation of an operation will be generated into the respective controller, component or service. However this tab shows any additional code artifacts that are generated and managed by the Spring DSL Operation. Each entry in this table represents a code artifact that is generated for the Operation. In addition to enabling and disabling code generation on an artifact-by-artifact basis, you can also customize the name of the artifact, the package used, and the location where the artifact is generated to.
Code Generation
The code generation settings can be specified at the project level, which will control the code generation settings for the entire project. The code generation settings can also be customized for each artifact using the code generation tab from the respective editor for the artifact.
For a description of the code generation settings available from the Service Editor, please refer the to Code Generation tab of the Project Editor.
The Spring DSL Web Flow is used for generating flows for Spring Web Flow and managing related source code and configuration files.
The Spring DSL Web Flow supports the creation of flows by:
providing a New Web Flow wizard
providing a Web Flow Editor for editing flows
The New Web Flow wizard is for adding a new Spring flow to the project.
New Web Flow >> New Web Flow >> Web Flow Domain
The New Web Flow window is for specifying the name of the flow and the model package that will contain the flow.
Table 4.38. New Web Flow Window
| Details | Description | ||
|---|---|---|---|
| File Name | Enter the desired file name in the File Name text box and click the Finish button. | ||
With Spring Web Flow the group of related steps to accomplish a task are referred to as a Flow. While authoring the flow of an application using XML is elegant, implementing flows using XML can be difficult and tedious because it’s hard to visualize the application flow from the xml. MyEclipse for Spring also provides a custom Spring Web Flow editor for authoring flows. You start with an empty canvas which represents a single flow, and you drop different web flow states (i.e. view, decision, action, subflow and stop) onto the canvas. State transitions are defined by drawing lines between the states and specifying the event associated with the transition. Actions can be added to flows and states.
The Spring DSL Domain Object is used for defining the domain layer of an application, and it's specifically responsible generating JPA Entities and managing related source code and configuration files.
The Spring DSL Domain Object supports the creation of JPA Entities by:
providing a New Domain Object wizard
providing a Domain Object Editor
generating JPA Entities (annotated with @Entity)
generating a JUnit test classes for component testing
The following sections describe the Domain Object wizards and editors.
The New Domain Object wizard is for creating new domain objects for a development project.
New Domain Object >> Domain Object
The New Domain Object window is for specifying the name of the domain object and the model package that will contain the domain object.
Table 4.40. New Domain Object Window
| Details | Description | ||
|---|---|---|---|
| Domain Object Name | Enter the name of the new Domain Object then click the Finish button. The Domain Object Editor is displayed. | ||
The Domain Object Editor is comprised of the Overview Tab, the Persistence Mapping Tab, and the Code Generation Tab. The follow sections describe each tab in detail.
The Service Editor can be used for configuring a Service in the Spring DSL or by right-clicking (Open-With) an @Service annotated java class.
The Overview tab is used for configuring the domain object fields, managing relationships and providing a description. Refer to the following figure and table for details on this tab.
This editor allows a user to describe the domain object, set relationships between other domain objects, and create and edit fields in the domain object. Refer to the following figure and table for details on this tab.
Table 4.41. Domain Object Editor - Overview Tab
| Details | Description | ||
|---|---|---|---|
| Name | Identifies the name of the new Domain Object. | ||
| Files | Click the Views link to display the generated source code. | ||
| Description | Enter a meaningful description for this Domain Object. | ||
| Relationships | Create and manage relationships between this and other Domain Objects by defining the Type, Name and Inverse Name. Click the Add button to add a Domain Object. | ||
| Fields | Create and edit fields in this domain object by defining Display Name, Type, and if whether it's a Collection. Click the Add button to add a field to this Domain Object. | ||
The domain object editor allows you to define relationships to a domain object.
Relationship Type
The Relationship Type defines the cardinality of the relationship from the perspective of the current Domain Object. The options are:
Table 4.42. Relationship Types
| Type | Description | ||
|---|---|---|---|
| One-to-One | a domain object is related to a single occurrence of the other domain object | ||
| One-to-Many | a domain object is related to many occurrences of the other domain object; the opposite side of a Many-to-One relationship | ||
| Many-to-One | a domain object is related to a single occurrence of the other domain object; the opposite side of a One-to-Many relationship | ||
| Many-to-Many | a domain object is related to many occurrences of the other domain object, and vice versa | ||
Bidirectional Relationships
When a relationship is added to another domain object, a unidirectional relationship is implied. Two independent unidirectional relationships can be linked together to create a bidirectional relationship. If you decide to define a bidirectional relationship, the cardinality and relationship names need to match.
Relationships Names
When defining a relationship between two data objects, the Domain Object editor will prompt you for a relationship name and a reverse name. These names will be used for accessing each other's related data. The relationship name is used to identify the relationship from the perspective of the current domain object. The reverse name is used to identify the relationship from the target data object type back to the current domain object.
Regarding relationship names, the Domain Object editor will default the domain object name as the relationship names, but you can very easily changed the name. It's a good idea to change these relationship names to something more semantically meaningful. While they have no impact on the functionality, these names will be the what you will see as your referencing these relationships in the services you create. These names should be meaningful, and it's recommended that you name them with the appropriate plurality for the relationship type.
The Persistence Mapping tab is used to control how the Domain Object will map into persistence in a database and how it will display throughout the rest of the project. This tab includes the Table and Field Mapping and Relationships sections. The Persistence Mapping tab will let you override the default table name and field names. Refer to the following figure and table for details on this tab.
Table 4.43. Domain Object Editor - Persistence Mapping Tab
| Details | Description | ||
|---|---|---|---|
| Table Name | Pre-populated with the name of the Domain Object by default. This name can be modified. | ||
| Schema | |||
| Catalog | |||
| Column Name | The name of the database column that this Field will be stored in. If left blank, the name of the Field will be used. This name is "suggested" as a user can override it during deployment. | ||
| Length | Length of text field. Default is 512 characters. | ||
| Precision | |||
| Scale | |||
| Fetch | Pull-down menu. Select the desired value of either Lazy, Eager, Unset. | ||
| Option | Select the desired column option. Valid values are: Insertable, Updateable, Nullable, and Unique. | ||
When a domain object in configured to be persisted to a database, the database name and fields will be derived from the domain object. However there are occasions where a developer may want the table names and field names to be different than the object. When a domain object is created, MyEclipse for Spring will use the following persistence mapping defaults:
Table name = domain object name
Table field names = domain object field names
This settings can be modified from this panel panel. The settings in this panel will drive the configuration of the ORM framework.
The Code Generation tab is for configuring the generation options for a Domain Object. This tab shows you all the code artifacts that are generated and managed by the Domain Object. Each entry in this table represents a code artifact that is generated for the Domain Object. In addition to enabling and disabling code generation on an artifact-by-artifact basis, you can also customize the name of the artifact, the package used, and the location where the artifact is generated to.
Code Generation
The code generation settings can be specified at the project level, which will control the code generation settings for the entire project. The code generation settings can also be customized for each artifact using the code generation tab from the respective editor for the artifact.
For a description of the code generation settings available from the Service Editor, please refer the to Code Generation tab of the Project Editor.
The Spring DSL Data Access Object is used for generating Spring @Repository components and and managing related source code and configuration files.
The Spring DSL Domain Object supports the creation of JPA Entities by:
providing a New Data Access Object wizard
providing a Data Access Object Editor
generating Spring @Repository componentsJPA Entities (annotated with @Entity)
generating a JUnit test classes for component testing
The following sections describe the Data Access Object wizards and editors.
The New Data Access Object wizard is for creating new data access objects for a development project.
New Data Access Object >> Data Access Object >> Add Domain Objects
The New Data Access window is for specifying the name of the data access object and the model package that will contain the data access object.
Table 4.44. New Data Access Object Window
| Details | Description | ||
|---|---|---|---|
| File Name | Enter the name of the new Data Access Object in the File Name text box then click the Next button to add a Domain Object. Data Access Objects can have duplicate names as long as they are stored in separate Services or in separate folders within a service. | ||
The Data Access Object Editor is comprised of the Overview Tab, the Database Configuration Tab, the Spring Bean Configuration Tab, and the Code Generation Tab. The follow sections describe each tab in detail.
The Overview tab is used for associating domain objects to the DAO, providing a description of the DAO, and navigating to the files generated from the DAO. Refer to the following figure and table for details on this tab.
Table 4.46. Data Access Object Editor - Overview Tab
| Details | Description | ||
|---|---|---|---|
| Name | Identifies the name of the new Data Access Object. | ||
| Files | Click the Views link to display the generated source code. | ||
| Description | Enter a meaningful description for this Data Access Object. | ||
| Domain Objects | Select and add Domain Objects to be managed by this Data Access Object. | ||
The Spring Bean Configuration tab is used to configure the scope and @Transaction annotations for the Data Access Object. Refer to the following figure and table for details on this tab.
Table 4.47. Data Access Object Editor - Spring Bean Configuration tab
| Details | Description | ||
|---|---|---|---|
| Enable Transaction | Specified whether the Spring transactional annotation should be emitted in this artifact's generated code | ||
| Read Only | Specifies a read-only transaction. | ||
| Timeout | Specifies how long a transaction may run before timing out. | ||
| Isolation | Specifies the degree of isolation this transaction has from the work of other transactions. | ||
| Propagation | Specifies the transaction propagation. | ||
| Rollback ClassNames | Specifies the exceptions that must cause a rollback. | ||
| No Rollback ClassNames | Specifies the exceptions that must not cause a rollback. | ||
| Scope | The scope for this bean. List of Available Scopes | ||
The Database Configuration tab allows a user to select a database for this Data Access Object. Refer to the following figure and table for details on this tab.
Table 4.48. Data Access Object Editor - Database Configuration Tab
| Details | Description | ||
|---|---|---|---|
| Connection | Select a database connection from the list of available databases in the drop-down menu. | ||
| Create New Connection | Click this link to invoke the New Connection Profile window. See the To Create a New Connection section for details on configuring a new connection. After creating a new connection it will become available in the Connection drop-down list. | ||
| Enable Persistence Provider SQL Logging | Select this checkbox to enable SQL Logging capability. | ||
| Allow Persistence Provider to create/update tables | Select this checkbox to allow the designated persistence provider to create/update tables to the database. | ||
| Minimum Connection Pool Size | Default value is 1. | ||
| Maximum Connection Pool Size | Default value is 10. | ||
| Enable XA Data Source | Select this checkbox to specify an XA Data Source. | ||
| XA Data Source Class Name | Enter the Data Source class name. | ||
The Code Generation tab is for configuring the generation options for a Data Access Object. This tab shows you all the code artifacts that are generated and managed by the Spring DSL DAO. Each entry in this table represents a code artifact that is generated for the DAO. In addition to enabling and disabling code generation on an artifact-by-artifact basis, you can also customize the name of the artifact, the package used, and the location where the artifact is generated to.
Code Generation
The code generation settings can be specified at the project level, which will control the code generation settings for the entire project. The code generation settings can also be customized for each artifact using the code generation tab from the respective editor for the artifact.
For a description of the code generation settings available from the Service Editor, please refer the to Code Generation tab of the Project Editor.
The following sections describe the Named Query wizards and editors.
The New Named Query wizard is for adding a new named query to a data access object.
New Named Query >> Named Query
The New Named Query window is for specifying the name of the named query and the data access object that will contain the named query.
Table 4.49. New Named Query Window
| Details | Description | ||
|---|---|---|---|
| Named Query Name | Enter the name of the new Named Query then click the Finish button to display the Named Query Editor. | ||
The Named Query Editor is comprised of the Overview Tab, the Input/Outputs Tab, the Query Text Tab, the Spring Bean Configuration Tab, and the Code Generation Tab. The follow sections describe each tab in detail.
The Overview tab is used for providing a description of the named query, navigating to the files generated from the named query, and navigating to the other Named Query configuration tabs. Refer to the following figure and table for details on this tab.
Table 4.50. Named Query Editor - Overview Tab
| Details | Description | ||
|---|---|---|---|
| Name | Identifies the name of the new Named Query. | ||
| Files | Click the Views link to display the generated source code. | ||
| Description | Enter a meaningful description for this Named Query. | ||
| Define Inputs and Outputs | Click this link to jump to the Inputs/Outputs tab. | ||
| Define the Query Text | Click this link to jump to the Query Text tab. | ||
The Inputs/Outputs tab defines the input and output parameters of a particular named query. When this query is invoked, the consumer of the name query is required to map variables to the input and output parameters. Refer to the following figure and table for details on this tab.
Table 4.51. Named Query - Inputs/Outputs tab
| Details | Description | ||
|---|---|---|---|
| Inputs | Inputs are a mechanism for exchanging data with the consumer of the named query. When a consumer calls a named query, they must provide all the input variables defined by the query. | ||
| Name | Identify the input parameter name. | ||
| Type | Select the data type of the parameter. In addition to primitive data types, an input parameter may have the type of a Domain Object. To select a Domain Object as the variable type, choose the Domain Object option from the Type drop-down menu. Select the desired data type from the data type picker and click OK. | ||
| Collection | Identify whether the parameter is a Collection. | ||
| Add | Click this button to add an input variable. The default is Input_1, incrementing as additional variables are added until they are renamed. | ||
| Outputs | Outputs are another mechanism for exchanging data with the consumer of the named query. When a consumer calls a named query, they must accept all the output variables defined by the named query. | ||
| Name | Identify the output parameter name. | ||
| Type | Select the data type of the parameter. In addition to primitive data types, an output parameter may have the type of a Domain Object. To select a Domain Object as the variable type, choose the Domain Object option from the Type drop-down menu. Select the desired data type from the data type picker and click OK. | ||
| Collection | Identify whether the parameter is a Collection. | ||
| Add | Click this button to add an output variable. The default is Output_1, incrementing as additional variables are added until they are renamed. | ||
The Query Text tab defines the query in either SQL or JPQL.Refer to the following figure and table for details on this tab.
Table 4.52. Named Query - Query Text tab
| Details | Description | ||
|---|---|---|---|
| Query Type |
Specifies the query language will be used in the named query. The options are:
|
||
| Query Text | Define the Query text to execute. | ||
| Insert | Click this button to invoke a Variable picker and select the input or output variable to include in the expression. | ||
| Edit Expression | Click this button to invoke the Expression Editor and build a valid expression. Click the OK button. | ||
The Spring Bean Configuration tab is used to configure the scope and @Transaction annotations for the Named Query. Refer to the following figure and table for details on this tab.
Table 4.53. Named Query Editor - Spring Bean Configuration tab
| Details | Description | ||
|---|---|---|---|
| Enable Transaction | Specified whether the Spring transactional annotation should be emitted in this artifact's generated code | ||
| Read Only | Specifies a read-only transaction. | ||
| Timeout | Specifies how long a transaction may run before timing out. | ||
| Isolation | Specifies the degree of isolation this transaction has from the work of other transactions. | ||
| Propagation | Specifies the transaction propagation. | ||
| Rollback ClassNames | Specifies the exceptions that must cause a rollback. | ||
| No Rollback ClassNames | Specifies the exceptions that must not cause a rollback. | ||
The following sections describe the Exception wizards and editors.
The New Exception wizard is for adding a custom exception to a project.
New Exception >> New Exception
The New Exception window is for specifying the name of the exception and the model package that will contain the exception.
Table 4.54. New Exception Window
| Details | Description | ||
|---|---|---|---|
| Exception Name | Enter the desired name for the Exception then click the Finish button. | ||
The Exception Editor is comprised of the Overview Tab and the Code Generation Tab. The follow sections describe each tab in detail.
The Overview tab is used for providing a description of the Exception, navigating to the files generated from the Exception, and navigating to the other Exception configuration tabs. Refer to the following figure and table for details on this tab.
Table 4.55. Exception Editor - Overview Tab
| Details | Description | ||
|---|---|---|---|
| Files | Click the Views link to display the generated source code. | ||
| Description | Provide a meaningful description of the Exception. | ||
The Code Generation tab is for configuring the generation options for an Exception. This tab shows you all the code artifacts that are generated and managed by the Spring DSL Exception. Each entry in this table represents a code artifact that is generated for the Exception. In addition to enabling and disabling code generation on an artifact-by-artifact basis, you can also customize the name of the artifact, the package used, and the location where the artifact is generated to.
Code Generation
The code generation settings can be specified at the project level, which will control the code generation settings for the entire project. The code generation settings can also be customized for each artifact using the code generation tab from the respective editor for the artifact.
For a description of the code generation settings available from the Service Editor, please refer the to Code Generation tab of the Project Editor.
A Model Package is a Spring DSL artifact for namespacing and grouping related Spring DSL components. A model package can contain any top-level Spring DSL elements, including other model packages. Model packages correlate directly to java packages (and UML packages), and Spring DSL artifacts created in a model package will be generated into a matching Java package.
In Java application development it is common to use packages for organizing and namespacing Java resources according to their functionality, and Model Packages serve the same purpose, except that they group generated artifacts.
The New Model Package wizard is for adding a new package to a project.
New Web Flow >> New Model Package
Table of Contents
The Spring Annotator guides you with configuring Spring stereotyped components, including Controller, Service, Componet and Repository.
The Spring Controller Annotator is for configuring Spring controllers. The annotator will show you annotation and configuration options that are relevant to Spring @Controllers.
When the class name is selected from the outline, the Controller tab will let you configure the class-level annotations for Spring controllers, and the Transactional tab will let you enable and configure the transactional properties of the controller.
When the class variable is selected from the outline, the Controller tab will let you configure the variable-level annotations for Spring controllers.
When the class method is selected from the outline, the Controller tab will let you configure the method-level annotations for Spring controllers, and the Transactional tab will let you enable and configure the transactional properties of the controller method.
The Spring Service Annotator is for configuring Spring services. The annotator will show you annotation and configuration options that are relevant to Spring @Services.
When the class name is selected from the outline, the Service tab will let you configure the class-level annotations for Spring services, and the Transactional tab will let you enable and configure the transactional properties of the service.
When the class variable is selected from the outline, the Service tab will let you configure the variable-level annotations for Spring services.
When the class method is selected from the outline, the Service tab will let you enable and configure the transactional properties of Spring service methods.
The Spring Component Annotator is for configuring Spring components. The annotator will show you annotation and configuration options that are relevant to Spring @Components.
When the class name is selected from the outline, the Component tab will let you configure the class-level annotations for Spring components, and the Transactional tab will let you enable and configure the transactional properties of the component.
When the class variable is selected from the outline, the Component tab will let you configure the variable-level annotations for Spring components.
When the class method is selected from the outline, the Component tab will let you enable and configure the transactional properties of Spring component methods.
The Spring Repository Annotator is for configuring Spring repositories. The annotator will show you annotation and configuration options that are relevant to Spring @Repositories.
When the class name is selected from the outline, the Repository tab will let you configure the class-level annotations for Spring repositories, and the Transactional tab will let you enable and configure the transactional properties of the repository.
When the class variable is selected from the outline, the Repository tab will let you configure the variable-level annotations for Spring repositories.
When the class method is selected from the outline, the Component tab will let you enable and configure the transactional properties of Spring component methods.
The JAX-WS Annotator is for configuring JAX-WS services. The annotator will show you annotation and configuration options that are relevant to JAX-WS.
When the class name is selected from the outline, the Web Service tab will let you configure the class-level web service annotations for JAX-WS services.
When the class name is selected from the outline, the SOAP Binding tab will let you configure the class-level SOAP binding annotations for JAX-WS services.
When the class method is selected from the outline, the Web Method tab will let you configure the method-level Web Method annotations for JAX-WS services.
When the class method is selected from the outline, the SOAP Binding tab will let you configure the method-level SOAP binding annotations for JAX-WS services.
When the class method is selected from the outline, the Request Wrapper tab will let you configure the method-level Request Wrapper annotations for JAX-WS services.
When the class method is selected from the outline, the Response Wrapper tab will let you configure the method-level Response Wrapper annotations for JAX-WS services.
When the class method is selected from the outline, the Parameters tab will let you configure the method-level parameter annotations for JAX-WS services.
When the class method is selected from the outline, the Web Result tab will let you configure the method-level Web result annotations for JAX-WS services.
The JPA Annotator is for configuring JPA entities. The annotator will show you annotation and configuration options that are relevant to JPA.
When the class name is selected from the outline, the Entity tab will let you configure the class-level annotations for JPA.
When the class name is selected from the outline, thee NamedQueries tab will let you configure the class-level annotations for JPA.
When the class name is selected from the outline, the NamedNativeQueries tab will let you configure the class-level annotations for JPA.
When the class variable is selected from the outline, the editor will let you configure the variable-level.
When the class variable is selected from the outline, the editor will let you configure the variable-level.
Table of Contents
Application layering is a very common architecture approach in the application development field. Application layering consists of separating application code into discrete layers that have a distinct responsibility in the application, and each layer is isolated from other layers. The following diagram shows the most common application layers in a web application.
The Spring framework has support for stereotype annotations which designate the layer/role of any annotated Java classes, and the annotations enable auto-detection of the classes. The next few sections will briefly introduce each layer and describe the relevant Spring stereotypes for eachlayer.
Since application layering is prevalent and has direct support from the Spring framework, MyEclipse for Spring advocates the use application layering and also organizes it's code generation/scaffolding capabilities arround application layering.
The web layer is also referred to as the UI layer. The web layer is primarily concerned with presenting the user interface and the behavior of the application (handling user interactions/events). While the web layer can also contain logic, core application logic is usually located in the services layer.
There are a lot of options regarding the implementation of the web layer. In regards to MyEclipse for Spring, some web layer implementations many not be directly related to Spring, however they may integrate with a Spring service layer and data access layer.
Here are some web layer examples (that also happen to be scaffolded by MyEclipse for Spring):
Spring MVC - JSP and Spring controllers (@Controller)
Spring Web Flow - JSP and Spring Flows (xml)
Adobe Flex - Adobe Flex specific; doesn't involve Spring web
Google Web Toolkit (GWT) - HTML/Javascript; AJAX
The service layer, which is also referred to as the logic layer or business layer, represents the core functionality of the application being built. The web layer is the primary consumer of the functionality provided by the service layer. The Spring framework utilizes the @Service annotation to designate service layer components. In addition to helping organize application logic, an additional benefit of using a service layer is that it can be exposed using other interfaces. For example if application logic needs to be available to other applications, it can be exposed as web services using JAX-WS. If the web layer is an AJAX application, the services can be exposed as javascript/JSON services using DWR.
The domain layer is is represented by a domain model; a distinct set of inter-related application objects that embody the functionality and characteristics of the system being built. In a web application this typically consists of JAVA Beans (POJO) and/or JPA Entities. The Spring component stereotype (@Component) is also non-entity beans that are going to be managed by the Spring framework.
The @Controller annotation is a specialized Spring stereotype for Spring MVC web layer components. Java classes annotated with @Controller are responsible for receiving requests from a web client (typically from end-user generated events) and invoking a request handler, which orchestrates all the server logic necessary for processing the request.
Relevant configurations:
See also: @Controller [Spring Framework - Reference Documentation]
The @Service annotation is a specialized Spring stereotype for service layer components. POJOs annotated with @Service are typically used to implement the business logic.
The logic found in a typical web application is associated with either (a) the behaviour of the application or (b) the business logic. While a Controller could technically be used to implement both the behavior and business logic, the best practice is for the web layer to be focussed on implementing the behaviour of the application, and the service layer focused on implementing the business logic.
Relevant configurations:
See also: @Service [Spring Framework - Reference Documentation]
The @Component annotation is a Spring stereotype for general purpose components, and they aren't specific do a particular application layer. The @Component annotation is used for POJOs that need to be managed by Spring, but aren't one of the more specialized components like @Controller, @Service or @Repository. A component isn't tied to any particular application layer, and it can be used for many different purposes, including the definition of data transfer objects (DTOs) in the service layer or form backing objects in the web layer.
Relevant configurations:
See also: @Component [Spring Framework - Reference Documentation]
The @Repository annotation is a Spring stereotype for data access layer components. Data Access Objects (DAO) is a pattern for separating data access logic from business logic. Data Access Objects are abstract representations of real databases (or persistence mechanisms), and they manage persistence for a set of JPA Entities (domain objects). When writing code to read, write, delete and update persisted data objects, with DAO there is no need to know the details of the database (vendor, version, IP, etc.).
See also: @Repository [Spring Framework - Reference Documentation]
An attribute on @Service, @Controller, @Component or @Repository annotations for uniquely identify the bean. If the bean name and id are omitted, Spring will generate a name from the class name. For an example how to reference a bean by it's bean name, see the @Resource annotation.
See also: Naming Beans [Spring Framework - Reference Documentation]
Scope is used to configure how a bean should be provisioned by the Spring container. Spring web applications support several scopes, and here are some of the most commonly used scopes:
Table 6.1. Spring Scopes
| Name | Description | ||
|---|---|---|---|
| singleton | one single bean instance per Spring container; default scope for Spring | ||
| prototype | new instance per bean request | ||
| request | one bean instance per HTTP request; every request will have a new bean instance | ||
| session | one bean instance per HTTP session; every session will have a new bean instance | ||
See also: Bean Scopes [Spring Framework - Reference Documentation]
The @RequestMapping annotation is used to map incoming URLs to request handlers, which can be a controller class or a controller method. When a request comes in that matches the specified URL path or pattern, the respective Java class/method will be used to handle the request.
See also: @RequestMapping [Spring Framework - Reference Documentation]
The request path (URL) or pattern that should be mapped to a class or method that's configured to be a request handler (@RequestMapping).
The specific HTTP methods that should be handled by a class or method that's configured to be a request handler (@RequestMapping).
Typical values:
GET - typically used to fetch data; data is passed in URL
POST - used to update data on server; data is passed in body
PUT - supported by HTTP; typically only used for REST-based request handlers
DELETE - supported by HTTP; typically only used for REST-based request handlers
Used to map a request parameter to an argument of a request handler. The @RequestParm annotation is applied on the method argument of a request handler. This provides the request handler with access to the request parameter. The Spring MVC framework will automatically extract and convert the parameter to the method argument type.
TODO
NONE Model Attribute Request Param +CookieVariable +PathVariable +RequestHeader +RequestBody
Specifies attributes that should be stored in session.
See also: @SessionAttributes [Spring Framework - Reference Documentation]
Used to customize the data binding for a controller. The Spring MVC has some default data binding. Both the @RequestParam and @ModelAttribute annotations convert (bind) the data to Java types, but the converters can be customized by an @InitBinder annotated method in the controller.
See also: @InitBinder [Spring Framework - Reference Documentation]
The annotation has two purposes:
When the @ModelAttribute annotation is applied on a method parameter of a request handler, it maps the model attribute (i.e. form backing object) to a request handler input parameter. This can be used provide the request handler with access to the form backing object. The Spring MVC framework will automatically convert the parameter to the method argument type.
When the @ModelAttribute annotation is applied on a controller method, the Spring MVC framework will execute the method prior to executing any request handlers. These methods will typically load reference data that will be used by all request handlers in the controller and/or views
See also: @ModelAttribute [Spring Framework - Reference Documentation]
The @Resource annotation is a Java annotation (JSR-250) supported by the Spring framework. The @Resource annoation is used for injecting Spring managed beans (dependencies) into a Java class. The bean to be injected is identified by bean name.
Spring also supports dependency injection using the @Autowired annoation.
See also: @Resource [Spring Framework - Reference Documentation]
The @Autowired annotation is a Spring annotation for injecting Spring managed beans into the current class.
See also: @Autowired [Spring Framework - Reference Documentation]
This is an optional true/false attribute that specifies whether the autowiring should fail if the dependency cannot be resolved. If this attribute isn't specified, Spring will default to true by convention.
Applies to both @Resource and @Autowired annotation. The name is used to provide the Spring Framework additional guidance on which Spring bean (by name) should be injected into the current class.
See also: @Resource [Spring Framework - Reference Documentation]
Qualifies the dependency resolution.
See also: @Qualifier [Spring Framework - Reference Documentation]
See also: @Transactional [Spring Framework - Reference Documentation]
Specifies a read-only transaction.
Specifies the transaction propagation.
Specifies the exceptions that must cause a rollback.
Specifies the exceptions that must not cause a rollback.
The @WebService annotation is used to identify JAVA classes that should be exposed as a SOAP web service endpoints.
Relevant configurations:
Name - the name of the Web Service; if omitted, defaults to class name
Namespace - the XML namespace used for the WSDL and XML elements generated from this Web Service.
Service Name -the service name of the Web Service.
Port Name -
Service Mode -
Binding Type -
Handler Chain File -
See also: JAX-WS [JSR-224]
The @SOAPBinding annotation is used to map the Web Service to a SOAP binding
Relevant configurations:
Style - the encoding style (DOCUMENT or RPC) for messages sent to/from Web Service; if omitted, defaults to DOCUMENT
Use - the formatting style (LITERAL or ENCODED) for messages sent to and from the Web Service; if omitted, defaults to LITERAL
Parameter Style - speficies whether method parameters represent the entire message body (BARE), or whether the parameters are elements wrapped inside a top-level element named after the operation (WRAPPED); if omitted, defaults to WRAPPED
See also: JAX-WS [JSR-224]
The @WebMethod annotation is used to identify methods that should be exposed as a Web Service operation.
Relevant configurations:
Name - the name of the service operation; if omitted, defaults to method name
Action - the action for the operation
See also: JAX-WS [JSR-224]
The @RequestWrapper annotation is used to specify the JAXB generated request wrapper bean and the element name and namespace for marshalling / unmarshalling the bean.
Relevant configurations:
Name - the local name of the element
Name Space - the namespace name of the element
Class Name - the name of the wrapper class
See also: JAX-WS [JSR-224]
The @ResponseWrapper annotation is used to specify the JAXB generated response wrapper bean and the element name and namespace for marshalling / unmarshalling the bean.
Relevant configurations:
Name - the local name of the element
Name Space - the namespace name of the element
Class Name - the name of the wrapper class
See also: JAX-WS [JSR-224]
The @WebParam annotation is used to map parameters Web Service parameters to method parameters.
Relevant configurations:
Name - the name of the Web Service parameter; if omitted, defaults to method parameter name
Name Space - The XML namespace for the parameter; if omitted, defaults to @WebService targetNamespace
Class Name -
See also: JAX-WS [JSR-224]
The @WebResult annotation is used to map the method return type to a Web Service result
Relevant configurations:
Name - the name of the Web Service result; if omitted, defaults to "return"
Name Space - The XML namespace for the parameter; if omitted, defaults to @WebService targetNamespace
Class Name -
See also: JAX-WS [JSR-224]
The @Basic annotation is used to specify the simplest mapping of an Entity property to a database column.
Relevant configurations:
See also: @Basic [JPA Ref] and JPA Wikibook.
The @Cacheable annotation is used to specify whether an entity should be cached. This annotation will only have an effect if JPA caching has been enabled.
Relevant configurations:
value - optional; TRUE or FALSE; specifies whether or not the entity should be cached; defaults to TRUE.
See also: @Cacheable [JPA Ref]
The @Column annotation is used to specify the mapped column for a persistent property. If no Column annotation is specified, the default values apply.
Relevant configurations:
See also: @Column [JPA Ref] and JPA Wikibook.
optional; the name of the database column; defaults to the name of the property of the entity class.
optional; the database table that contains the column; defaults to the Entity's database table
Whether the column is included in SQL INSERT statements generated by the persistence provider.
See also: JPA Wikibook.
Whether the column is included in SQL UPDATE statements generated by the persistence provider.
See also: JPA Wikibook.
The operations that must be cascaded to the target of the association
Relevant configurations:
type - ALL DETACH MERGE PERSIST REFRESH REMOVE
See also: cascade [JPA Ref] and JPA Wikibook.
Whether the association should be lazily loaded or must be eagerly fetched.
Relevant configurations:
type - EAGER LAZY
See also: fetch [JPA Ref] and JPA Wikibook.
The @Embeddable annotation is used to specify a class that is part of an owning entity.
See also: @Embeddable [JPA Ref] and JPA Wikibook.
The @EmbeddedId annotation is used to specify the composite primary key of an embedded class.
See also: @EmbeddedId [JPA Ref] and JPA Wikibook.
The @Entity annotation is applied to a class that is to be persisted using JPA and specifies that the class is an entity.
Relevant configurations:
name - optional; the entity name to be used in queries. defaults to the entity class name.
See also: @Entity [JPA Ref] and JPA Wikibook.
The @EntityListeners annotation is used to specify a callback listener class to be used for an entity or mapped superclass to designate methods that should be executed during lifecycle events.
Relevant configurations:
value - required; the callback listener classes
See also: @EntityListeners [JPA Ref]
The @Enumerated annotation is used to specify that a persistent field should be persisted as a enumerated type.
Relevant configurations:
value - optional; the type used in mapping an enum type; ORDINAL or STRING; defaults to ORDINAL
See also: @Enumerated [JPA Ref] and JPA Wikibook.
The @ExcludeDefaultListeners annotation is used to specify that the invocation of default listeners is to be excluded for the entity class or mapped superclass.
See also: @ExcludeDefaultListeners [JPA Ref]
The @ExcludeSuperclassListeners annotation is used to specify that the invocation of superclass listeners is to be excluded for the entity class or mapped superclass.
See also: @ExcludeSuperclassListeners [JPA Ref]
The @GeneratedValue annotation is used to specify the generation strategy of a primary key field of an entity.
Relevant configurations:
generator - optional; the generator to use; defaults to a generator specified by JPA provider
strategy - optional; AUTO, TABLE, SEQUENCE, IDENTITY; defaults to AUTO.
See also: @GeneratedValue [JPA Ref] and JPA Wikibook.
The @IdClass annotation specifies the composite primary key class. A composite primary key class must be used when there are multiple primary key fields for an entity.
Relevant configurations:
name - the primary key class
See also: @IdClass [JPA Ref] and JPA Wikibook.
The @Id annotation specifies the primary key of an entity.
See also: @Id [JPA Ref] and JPA Wikibook.
The @Inheritence annotation is used to specify the inheritance strategy to be used for an entity class hierarchy. It is specified on the entity class that is the root of the entity class hierarchy.
Relevant configurations:
strategy - JOINED, SINGLE-TABLE, or TABLE_PER_CLASS
See also: @Inheritence [JPA Ref] and JPA Wikibook.
The @NamedQuery annotation is used to specify a pre-defined JPA named query for an entity.
Relevant configurations:
See also: @Column [JPA Ref] and JPA Wikibook.
optional; the name of the database column; defaults to the name of the property of the entity class.
optional; the database table that contains the column; defaults to the Entity's database table
The @JoinColumns annotation is used to specify multiple join columns. It serves as a container for multiple instances of the @JoinColumn annotation.
Relevant configurations:
value - one or more @JoinColumn annotations
See also: @JoinColumns [JPA Ref]
The @JoinTable annotation is used to specify associations.
Relevant configurations:
catalog - optional; the catalog of the table
inverseJoinColumns - optional; the foreign key columns from the opposite relationship; an array of @JoinColumn
joinColumns - optional; the foreign key columns from the owning relationship; an array of @JoinColumn
name - optional; the name of the join table
schema - optional; the schema of the table
uniqueConstraints - optional; unique constraints
See also: @JoinTable [JPA Ref]
The @Lob annotation is used to specify that a persistent field should be persisted as a large object to a database-supported large object type.
See also: @Lob [JPA Ref] and JPA Wikibook.
The @ManyToMany annotation is used to specify a a many-valued association with many-to-many multiplicity.
Relevant configurations:
See also: @ManyToMany [JPA Ref] and JPA Wikibook.
The @ManyToOne annotation is used to specify a single-valued association to another entity class that has many-to-one multiplicity.
Relevant configurations:
See also: @ManyToOne [JPA Ref] and JPA Wikibook.
The @NamedNativeQueries annotation specifies multiple named native queries. It serves as a container for multiple instances of the @NamedNativeQuery annotation.
Relevant configurations:
See also: @NamedNativeQueries [JPA Ref] and JPA Wikibook.
The @NamedNativeQuery annotation specifies a named native SQL query.
Relevant configurations:
Name - the name of the Web Service result; if omitted, defaults to "return"
Name Space - The XML namespace for the parameter; if omitted, defaults to @WebService targetNamespace
Class Name -
See also: @NamedNativeQuery [JPA Ref] and JPA Wikibook.
The @NamedQueries specifies multiple JPA named queries. It serves as a container for multiple query instances of the @NamedQuery annotation.
Relevant configurations:
value - one or more NamedQuery annotations
See also: @NamedQueries [JPA Ref] and JPA Wikibook.
The @NamedQuery annotation is used to specify a pre-defined JPA named query for an entity.
Relevant configurations:
name - required; the name of the query
query - required; a JPA query language query
hints - a collection of query hints (see @QueryHint)
See also: @NamedQuery [JPA Ref] and JPA Wikibook.
The @MappedSuperclass annotation is used to specify a class whose mapping information is applied to the entities that inherit from it.
Relevant configurations:
See also: @MappedSuperClass
[JPA Ref]http://en.wikibooks.org/wiki/Java_Persistence/Embeddables#Embeddables
The @OneToMany annotation is used to specofy a many-valued association with one-to-many multiplicity.
Relevant configurations:
orphanRemoval
See also: @OneToMany [JPA Ref] and JPA Wikibook.
The @OneToOne annotation is used to specify a single-value association to another entity that has one-to-one multiplicity.
Relevant configurations:
orphanRemoval
See also: @OneToOne [JPA Ref] and JPA Wikibook.
The @OrderBy annotation is used to specify the ordering of the elements at the point when the association or collection is retrieved.
Relevant configurations:
value - order by list
See also: @OrderBy [JPA Ref] and JPA Wikibook.
The @QueryHint annotation is used to provide properties or hints to named queries.
Relevant configurations:
name - name of the hint
value - value of the hint
See also: @QueryHint [JPA Ref] and JPA Wikibook.
The @Table annotation specifies the primary database table for the annotated entity. The class will be mapped to the specified table.
Relevant configurations:
name - optional; the database table name. defaults to entity name.
catalog - optional; the database catalog name. defaults to default catalog.
schema - optional; the database schema name. defaults to default schema.
See also: @Table [JPA Ref] and JPA Wikibook.
The @Temporal annotation is used to specify persistent fields of type java.util.Date and java.util.Calendar.
Relevant configurations:
value - temporal type
See also: @Temporal [JPA Ref] and JPA Wikibook.
The @Transient annotation is used to specify that the property is not persistent.
See also: @Transient [JPA Ref] and JPA Wikibook.
The @Version annotation is used to specify the version field or property of an entity class that serves as its optimistic lock value.
See also: @Version [JPA Ref] and JPA Wikibook.
Table of Contents
Spring MVC is a web framework from the creators of the Spring. While it isn't the only Spring-based web framework, it is one of the mostly commonly used web frameworks.
Spring MVC supports multiple approaches for implementing the web layer, and Spring 2.5 added support for an annotation-based programming model. The annotation-based approach has quickly become the predominent way of using Spring MVC, and it's generally regarded as the best practice in Spring MVC development. The scaffolding functions of MyEclipse for Spring will generate the web layer using the annotation-based programming model.
Spring Web Flow is a project from Spring for simplifying the development of web applications. While Spring Web Flow is compatible with Spring MVC, Spring Web Flow uses flows instead of controllers for implementing the web layer of an application. Since Spring Web Flow has functionality for managing application state, it is best suited for implementing the functionality where the activity being performed by the end-user spans multiple page requests, all the pages need to be treated as a unit of work.
Flows are a group of related steps for accomplishing a task in an application. Some of the benefits of using Spring Web Flow are
XML-based flow definitions - The flow of the application is defined in XML. No custom Java is needed to implement a flow
Expression language support - An expression language let’s you leverage logic from the other layers of the web application. Logic that a developer would typically put into a controller, that isn’t handled by Spring Web Flow, can be expressed in XML using the expression language
State management - Variables can be scoped (many scopes are supported), and Spring Web Flow will automatically handle the cleanup of those variables when they are out-of-scope.
Modularization of flow logic - Flows can be re-used from other flows.
A Flow is responsible for orchestrating the task (steps) and supporting the user events associated with the task. Instead of the MVC-based approach of creating one or more controllers and multiple request handlers for implementing a conversation, with Spring Web Flow you define a flow with states and expressions. Instead of the MVC-based approach of defining request mappings, with Spring Web Flow you define events. Spring Web Flow also let's you easily separate your logic for handling a user event (on event id) from the pre-load logic (on entry) for a particular state.
JavaServer Faces (JSF) is a standardized, component-based, and event-driven web framework for building user interfaces for Java web applications. It's goals are to simplify the development of user interfaces using XML-based view template language that can easily integrate with backend code written by Java developers. Primefaces is a component library for JSF 2.0, and it provides a rich set of UI components that can be easily used with JSF.
Adobe Flex is a software development kit for building rich internet applications (RIA) that run inside a browser plugin.
Google Web Toolkit (GWT) is a software development kit for building rich internet applications that run inside a html/javascript browser.
The iPhone web client is an web application that suitable for iPhone web browers. The foundation for the application is a Spring MVC client with the JSP pages generated using iWebKit for giving the application an iPhone look and feel.
Table of Contents
What get's generated?
Table 8.1. Spring MVC Scaffolding - What get's generated?
| Item | Description | ||
|---|---|---|---|
|
Stateless annotation-based multi-action Spring Controllers (@Controller) |
one controller per top-level domain object; each controller handles all users events for the managing domain object and related domain objects; including list, view, delete and add.
|
||
|
Fully implemented request handlers |
integrated with Service and DAO layers using Spring dependency injection
|
||
|
JUnit tests |
one test method per request handler
|
||
|
JSP pages |
using JSTL, Spring form/javascript tag library; one set of pages per domain object Edit page - for editing and creating new records; localized; client-side validation
View page - for read-only view of a record and listing related children records; localized
List page - for listing all top-level records; localized
|
||
|
Application-level UI components |
one set per application Header
Footer
Dashboard
|
||
|
Sitemesh configuration |
for layout management
|
||
|
Look and Feel |
|
||
|
Spring context files for web layer |
|
||
|
Internationalization Support |
Localization bundles
|
||
|
Other generated applications layers to support Spring MVC application |
What get's generated?
Table 8.2. Spring Web Flow Scaffolding - What get's generated?
| Item | Description | ||
|---|---|---|---|
|
Flows (Spring Web Flow) |
one flow per domain object; each flow handles all users events for the managing domain object and related domain objects; including list, view, delete and add
|
||
|
Fully implemented request handlers |
integrated with Service and DAO layers using Spring dependency injection
|
||
|
JUnit tests |
one test method per request handler
|
||
|
JSP pages |
using JSTL, Spring form/javascript tag library; one set of pages per domain object Edit page - for editing and creating new records; localized; client-side validation
List page - for listing all top-level records; localized
View page - for read-only view of a record and listing related children records; localized
Delete page - for confirming deletion of record
|
||
|
Application-level UI components |
one set per application Header
Footer
Dashboard
|
||
|
Sitemesh configuration |
for layout management
|
||
|
Look and Feel |
|
||
|
Spring context files for web layer |
|
||
|
Internationalization Support |
Localization bundles
|
||
|
Web Flow Diagrams |
for maintaining a web flow using graphical interface; each generated flow will have a matching diagram
|
||
|
Other generated applications layers to support Spring Web Flow application |
What get's generated?
Table 8.3. JSF 2.0 Scaffolding - What get's generated?
| Item | Description | ||
|---|---|---|---|
|
Managed Bean |
one managed bean per domain object; each bean handles all users events for the managing domain object and related domain objects; including list, view, delete and add
|
||
|
Fully implemented request handlers |
integrated with Service and DAO layers using Spring dependency injection
|
||
|
XHTML pages |
using JSF and Primefaces; one set of pages per domain object Edit page - for editing and creating new records; localized; client-side validation
List page - for listing all top-level records; localized
View page - for read-only view of a record and listing related children records; localized
Delete page - for confirming deletion of record
|
||
|
Application-level UI components |
one set per application Header
Footer
Dashboard
|
||
|
Sitemesh configuration |
for layout management
|
||
|
Look and Feel |
|
||
|
Spring context files for web layer |
|
||
|
Internationalization Support |
Localization bundles
|
||
|
Other generated applications layers to support Spring Web Flow application |
What get's generated?
Table 8.4. Adobe Flex Scaffolding - What get's generated?
| Item | Description | ||
|---|---|---|---|
|
Declarative UI components for Adobe Flex |
Listing and Detail - for read-only view of a record and listing related children records
Edit Form - for editing and creating new records; client-side validation
|
||
|
Event handler in Actionscript |
|
||
|
Domain model in Actionscript |
|
||
|
Look and Feel |
|
||
|
Spring context files for Flex integration |
|
||
|
Flex configuration files |
|
||
|
Flex compilation ant script |
|
||
|
Other generated applications layers to support Adobe Flex application |
TODO
What get's generated?
Table 8.5. iPhone Web Scaffolding - What get's generated?
| Item | Description | ||
|---|---|---|---|
|
Stateless annotation-based multi-action Spring Controllers (@Controller) |
one controller per top-level domain object; each controller handles all users events for the managing domain object and related domain objects; including list, view, delete and add.
|
||
|
Fully implemented request handlers |
integrated with Service and DAO layers using Spring dependency injection
|
||
|
JUnit tests |
one test method per request handler
|
||
|
JSP pages |
using JSTL, Spring form/javascript tag library; one set of pages per domain object Edit page - for editing and creating new records; localized; client-side validation
View page - for read-only view of a record and listing related children records; localized
List page - for listing all top-level records; localized
|
||
|
Application-level UI components |
one set per application Footer
Dashboard
|
||
|
Sitemesh configuration |
for layout management
|
||
|
Look and Feel |
|
||
|
Spring context files for web layer |
|
||
|
Internationalization Support |
Localization bundles
|
||
|
Other generated applications layers to support iPhone Web application |
The service layer blueprint applies to the Spring MVC, Spring WebFlow, JavaServer Faces (JSF 2.0), Adobe Flex, Google Web Toolkit (GWT), and iPhone web layer blueprints.
Table 8.6. Service Layer Scaffolding - What get's generated?
| Item | Description | ||
|---|---|---|---|
|
Service Interface |
|
||
|
Stateless Spring Service w/ transaction management (@Service) |
|
||
|
Fully implemented service methods |
integrated with DAO layer using Spring dependency injection |
||
|
JUnit tests |
one test per service method
|
||
|
Spring context file for service layer |
|
||
|
Other configuration files |
|
The domain layer blueprint applies to the Spring MVC, Spring WebFlow, JavaServer Faces (JSF 2.0), Adobe Flex, Google Web Toolkit (GWT), and iPhone web layer blueprints.
Table 8.7. Domain Layer Scaffolding - What get's generated?
| Item | Description | ||
|---|---|---|---|
|
JPA Entities w/ a full set of JPA Named Queries |
|
||
|
Primary Key Classes |
|
This persistence layer blueprint applies to the Spring MVC, Spring WebFlow, JavaServer Faces (JSF 2.0), Adobe Flex, Google Web Toolkit (GWT), and iPhone web layer blueprints.
Table 8.8. Persistence Layer Scaffolding - What get's generated?
| Item | Description | ||
|---|---|---|---|
|
DAO Interface |
|
||
|
Spring Repository (@Repository) |
|
||
|
Fully implemented persistence methods | |||
|
JUnit tests |
one test per DAO function
|
||
|
Spring context file for DAO layer |
|
||
|
Other configuration files |
|
Table of Contents
This panel controls the Spring Code Generation preferences of the current MyEclipse workspace.
Thank you for you interest in MyEclipse for Spring. If you are interested in learning more, the following developer resources are available:
Reference - Eclipse Help (MyEclipse for Spring 10.0 --> MyEclipse for Spring Reference) or Education Materials (online)
Tutorials - Eclipse Help (MyEclipse for Spring 10.0 --> Tutorials) or Education Materials (online)
Screencasts - MyEclipse for Spring YouTube Channel (online)
Support Forums - MyEclipse for Spring Forums (online)
Blog - MyEclipse for Spring Posts (online)
