EnterpriseJava69

Java EE support in NetBeans 6.9

Author: DavidKonecny
Version: draft 0.7.1

Contents


Focus

One of the themes of NetBeans 6.9 will be to expand and improve existing support for Java EE 6. There is always space to improve existing support, implement requested enhancements or missing features, lower defect count, etc. And in Java EE support area this is even more valid because of the vast feature set being covered. Obviously not everything can be addressed in one release and therefore prioritizing and focusing on one or two particular areas is essential.

For NetBeans 6.9 user's productivity with Java EE 6 will be in spotlight. Typical Java EE 6 application is using Java Persistence and Java Server Faces. Popularity of simplified Enterprise Beans will be growing and it is likely that adoption of Web Beans will rise as it is official Java EE platform dependency injection mechanism. Last major area which should not be missed out is Web Services. Looking at these 5 technologies and how they complement each other and making sure that IDE provides support which seamlessly spans over these five technologies will be the focus for NetBeans 6.9. Instead of addressing these technologies individually they will be looked at from the point of view of architecture of end user's application and what IDE features user needs in order to implement their application. That also means that for this planning document width of available feature set is more important then depth of individual features.

Sound application architecture separates data layer (often called business domain or problem domain) from user interface and that is separation which will be followed by the rest of this planning document.

Data Layer

It is pretty safe to state that majority of web applications are using database backend to persist some data or application state. To develop a data layer of such application involves many of these tasks:

  • database creation/manipulation/maintenance
    • (re)create DB from script
    • (re)populate DB with initial data
    • browse data/perform queries/alter db structure
    • capture and persist DB schema of existing DB
  • access database from Java
    • (re)define connection between Java and DB (Persistence Unit in JPA terminology)
    • (re)generate JPA entities from DB; or
    • write JPA entity classes by hand and (re)generate DB from them
    • write/(re)generate data controller for JPA entity manipulation (create, retrieve, update, delete)
  • implement business requirements
    • add custom queries, data manipulations, application logic, ...
    • test business logic
    • preview output of business logic
  • create data layer interface
    • define Java API interface
    • provide EJB interface
    • provide Web Service interface

While most of the identified tasks are supported by NetBeans there are many which are not that well integrated into user's workflow. These areas and missing features will be addressed in separate chapters. More detailed specifications will be needed in many cases and these will be created as needed.

Introduce Database node to project logical view

Current project types do not communicate clearly that they are using database and make no effort to make user's database tasks easier. All functionality related to database maintenance and connections is provided via Database node in Services tab which is free of project context. First proposed amendment is therefore to add new Database node to project's logical view. The purpose of this node would be to communicate to user project's:

  • data sources
  • persistence units
  • entity classes
  • SQL scripts
  • EJB facades/Web Services exposing data

and allow users quickly manage these. Following tasks are to be implemented on the node:

DB1.1: list available project Data Sources, that is DSs available on project's application server and DSs defined in server specific files (eg. GlassFish's sun-resources.xml); allow their managing - adding a new one, removing server specific ones, etc.; allow browsing of data (shortcut to functionality available in Services | Databases node)

DB1.2: annotate list of Data Sources with Persistence Unit name if PU exists for DS, eg. "jdbc/sample (WebApplicationPU)"; if multiple PUs are using the same data source then the data source should be listed many times with different PU name; allow creation of new PU

DB1.3: list project's persistence.xml file (should it be removed from Configuration Files node? Should creation be supported for persistence.xml as is or PU creation is sufficient).

DB1.4: list project's JPA entity classes; allow creation of new JPA entity classes

DB1.5: enable to regenerate JPA entities from DB

DB1.6: enable DB (re)creation from JPA entities; enable SQL script generation from JPA entities (is this doable?)

DB1.7: enable capturing SQL script (structure and/or data) of an existing DB (is it doable?)

DB1.8: list SQL scripts defined within project; allows their execution on one of project's PU; enable creation new SQL scripts

DB1.9: list EJBs used for JPA manipulation (UI should associate EJBs with their JPAs); allow their (re)creation

DB1.10: list Web Services for data access (to be clarified); allow their (re)creation;

Simplify Persistence Unit creation

There is certain illogic and redundancy in UI for persistence unit handling. It is most likely because PU is commonly used but its usage is optional and therefore UI cannot enforce it. For example "Entity From DB" wizard always starts by asking for Data Source regardless of whether project already has PU or not. And on second wizard panel it allows to create PU (if none exists yet) and allows to select different Data Source then one used on first wizard panel which does not make much sense.

This should be amend by presenting these two architectural concepts in UI as single element. Wherever Data Source is shown and presence of PU is relevant then Data Source name should be annotated with PU name, that is for example instead of listing just "jdbc/sample" in Entity From DB wizard there should be "jdbc/sample (WebProjectPU)" in case project already has persistence unit named "WebProjectPU" for "jdbc/sample" data source. And similarly if data source was selected which does not have persistence unit then checkbox should be shown in UI, eg. "[x] Create Persistence Unit", which will result in PU being created with selected DS and defaulted name. If multiple persistence units exist for the same data source then data source should be listed multiple times and annotated with different persistence unit names.

DB2.1, Done: remove "create persistence unit" button and logic and visualize PUs via data source names; allow automatic PU creation with default values

DB2.2, Done(table selection from persistence is used now, not sure if more can be done as last step is different in functionality): update Rest From DB wizard to use the same wizard as Entity From DB (to eliminate discrepancies between these two)

Allow code regeneration

Once JPA/EJB classes are generated from entities there is not way to refresh them after structural DB change. Project should ideally remember which classes were automatically generated and allow their regeneration without forcing user to go through the same wizard again. Operation should be as simple as right clicking Database node in project's logical view and choosing action "Regenerate Existing Entities from DB". Ideally source code diff would be shown to user before changes are applied similarly to Java Refactorings.

DB3.1 Done : enhance existing wizards with "overwrite existing files" option (Entity From DB, EJB From JPA, Rest From DB, ...) (for example Rest From DB generated invalid Java code - everything is twice in the class)

DB3.2: add "Regenerate code"(?) action to Database's node or similar mechanism to automate regeneration

DB3.3 Done : change generated EJB Facade code to be based on abstract class using generics to implement common code

DB3.4: Rest from DB wizard should not generate its own data controller but reuse EJB facade generator used by JPA from DB wizard

Drop DB Schema generation (aka Offline Database)

Generated .dbschema file has two usages: it is necessary in runtime for CMP EJBs; and JPA entities can be generated from it. It is read-only/offline image of database structure but it's current usefulness is very limited - it cannot be altered/enhanced; it cannot be created from scratch; it cannot be used to recreate DB; it does not show many details of DB structure; etc.

DB4.1: consider dropping this feature from most of the UI and keep it only for CMP EJB case, eg. remove it from Entity From DB wizard etc.

Improve JPA Entities generator

DB5.1: [moved to 6.10 plan] retrieval of table names in "Entities From DB" wizard can be extremely slow (takes several minutes on certain databases); possibly it may be caused by retrieving complete DB structure; either change that or allow filtering of table names to retrieve; need to be evaluated

DB5.2: [moved to 6.10 plan] in JPA entity wizard consider adding customizer for names and types of generated entity fields as well as selector of which named queries to generate

DB5.3: implement "JPA entity" insert code action which would list class fields and act similarly as Getters and Setters generator but in addition it would allow to configure in UI some other JPA and beans validation annotations

DB5.4: JPA entity generator should generate bean validation annotations (eg. Mix, Max, etc.)

DB5.5: allow to generate EJBs (and possible Web Services?) directly in Entities wizard so that whole data layer Java code is generated in one wizard

Miscellaneous Tasks

DB6.1: provide insert code template for creating finders/named queries (including implementation), ie. generate finder or named query based on the user selecting columns and conditions (such as equals, less than, like, in etc). (for inspiration have a look at Dynamic Finders in Grails)

DB6.2: evaluate and consider support for Spring transactions (to be clarified)

DB6.3: [moved to 6.10 plan] merge Rest Services and Web Services project logical nodes together; in general make sure that the same UI is used regardless of service technology, for example replace 'Test Rest WS' in project's node with more generic "Test WS" action which works for in both service type cases

DB6.4: make sure wizards (JPA, EJB, WS, ...) remember last used values and pre-populate itself whenever possible, eg. package for EJBs, JPAs, will quite likely be the same in one project

DB6.5: evaluate if unit testing of data layer is easy to do (eg. should some memory based DB be automatically bundled with IDE?, etc.)

DB6.6: [moved to 6.10 plan] warn user about usage of optional Java EE packages - issue 178757

DB6.7: IDE does not generate metamodel classes for managed JPA entities - issue 178108

Other relevant documents

User Interface Layer

This is TBD and likely it may have to wait for next release after NetBeans 6.9.

For the JSF (Facelets) editing area, there is a separate wiki page here.

Not logged in. Log in, Register

By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2012, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo