NewFeaturesForJavaEE6
Contents
|
This document is just a list of things that might make sense in a Java EE 6 development environment, extrapolating from Netbeans 6.5.
1 Enterprise Beans Support
1.1 Embedded EJB
In Java EE 6 a the EJB container will now be able to be embedded into applications. By embedding an EJB container into an application will allow an EJB to be run outside of an applicaiton server. Unit test will most likely be the biggest use case for using embedded EJB containers. However the uses of the embedded container will not be limited to Use Cases.
Priority: P3
1.1.1 Test Support
- Unit Test Code Generation Wizard: When generated a unit test for a EJB the users should be asked if they desire to use the embedded container. The question should be asked if the supporting server supports JEE 6 or greater.
- Update Classpath: The test classpath needs to be updated to include the embedded container jar file.
- Update Templates: The unit test template should generate the embedded container initialization code, as well as the clean up code.
1.1.2 Executing Main Classes
- Add Main Method Code Generator: The main method code generator would add the container initialization and deinitialization.
- Add Main Method Executor to Beans: The action should only be present if the server supports embedded containers and the bean has a main method.
- Executing a main class: The execution action would have to make sure that the embedded container jar file is in the classpath.
1.2 Optional Local Interfaces
In JEE 6 local interfaces are now optional. The NetBeans enterprise bean support will need to be updated to support beans without local interfaces.
Priority: P2
1.2.1 Update Code Generators
The enterprise bean code generators will need to be updated to generate beans without local interfaces. The new code generators should only be executed if the server supports JEE 6.
1.2.2 Easy Annotation of public methods
Since local interfaces are no longer required, I am assuming that a method will not be annotated as a special public method. If this is the case, we may want to make this easy. However it may be that the bean will be treated as a POJO to other local instances. In this case nothing will need to occur.
1.2.3 Update the "Call Enterprise Bean" Code Generator
Since the local interfaces are no longer required, the code used to look up an EJB from the JNDI lookup needs to be modified.
1.3. Enterprise Beans Annotation Support
Priority: P2
1.3.1 Code Completion
1.3.2 Hints for Annotations
1.4 Deployment Descriptor
In JEE 5 the ejb-jar.xml file became an optional configuration file. The information that was in the configuration file can now be specified in the enterprise beans source files. Because concerns of how to represent configuration information that is spread out amoung multiple files, the editor for the ejb-jar.xml file no longer uses the nice XML multi-view editor tabs. Instead the editor is a plan XML file editor. Therefore supporting the new deployment descriptor data should not be a problem.
In the future we should add a nice deployment descriptor editor that merges the annotated data and the deployment descriptor information into one editor. This kind of editor would make it easier to manipulate the annotations embedded in the enterprise beans.
Priority: P2
1.4.1 Code completion
This is pretty trivial.
1.4.2 Hints
If there is hint support in xml files, it would be nice to support hints in the XML view. This may be a middle ground, between the "raw xml" and a multiview editor, that is cheaper to create.
1.5 Singleton Session beans support
Singleton session bean support has been added to JEE 6. Either another new file wizard will have to be added or a check box will have to be added to the current session bean wizard. If a new check box is added the wizard it must be hidden or disabled with the project is not using JEE 6.
Priority: P3
2 Java Web Support
2.1 Enterprise Bean Packaging
In JEE 6 enterprise beans can be packaged in standard War files. The war file has not changed, it simply can now contains enterprise beans. However to EJB support consistent between the EJB Module and the Web Module there will need be some changes made to the web project.
2.1.1 Add an Enterprise Bean Node
The new node will behave the same as the EJB module project.
Priority: P1.5
2.1.2 Update New File Wizard
The New file wizard must allow EJB module files to be created inside of web projects. This includes but is not limited to Enterprise beans and the ejb-jar.xml configuaration file.
Priority: P1
2.2.3 Update the "Call Enterprise Bean" Code Generator
Since the local interfaces are no longer required, the code used to look up an EJB from the JNDI lookup needs to be modified. Also since the web project will be able to own Enterprise Beans, the wizard must also find beans that are in the web project as well as other EJB modules.
Priority: P1
- Update the JNDI lookup calls if the project is using JEE 6
- The Generator must also search for Beans in the web project as well as EJB modules.
2.2 Servlet Support
In JEE 6 servlets now have a suite of annotations that can be used to specifies a servlet's configuration. These new annotations will need to be supported in NetBeans.
2.2.1 Update Servlet Wizards
The servlet wizards will need to generate servlet code that use the new servlet annotations. The new code generator should only be executed if the server supports JEE 6. These affected wizards will include but will not be limited to the servlet and filter new file wizards.
Priority: P1
2.3 web.xml Support
In JEE 6 the web.xml file will become optional. Changes to the web project will be needed to respect the optional nature of the web.xml file.
Priority: P1
2.3.1 No longer generate the web.xml file
Currently the web.xml file is automatically created when creating a web project. If the server support JEE 6 web.xml file should no longer be generated.
Priority: P1
2.3.2 Wizard to create a web.xml file
A new wizard should be added to create a skeleton web.xml file. Graphical editing is not supported. Plain XML editing only.
Priority: P1
2.3.3 Add a new event mechanism to replace the web.xml model
Replicating the functionality we have in ejbjar.xml towards web.xml.
Priority: P1
2.4 Fragment Deployment Descriptors Support
JEE 6 will allow fragment deployment descriptors to be used. The appliciation server will merge the fragment deployment descriptors with the actual deployment descriptor and the annotated classes to create a complete deployment descriptor. The fragment deployment descriptor will be useful for web frameworks like spring. The fragment deployment descriptor will be a simplified web.xml file.
If the fragment deployment descriptor has a different schema than the web project web.xml file then a fragment model may be required.
2.4.1 Create a fragment web.xml wizard
This requirement is only neccessary if the fragment web.xml file has a different schema than the web project web.xml file. If a new schema is not specified for the fragment web.xml file then the standard web project web.xml file wizard can be used.
Priority: P3
2.4.2 Create a set of hints/error annotations for xml elements that are not available in the fragment xml file.
This requirement is only neccessary if the fragment web.xml file has a different schema than the web project web.xml file. If there is not a new schema it would not be possible for NetBeans to determine only a subset of configuration elements are available.
Priority: P3
2.4.3 Create a Web Framework project type.
Since JEE 6 seems to be defining a difference between web applications and web frameworks it would be nice to have a NetBeans project that is designed to support a web framework. However this may not be a highly used project type and therefore may not be required.
Priority: P5
- Initialize with basic framework requirements.
- Creates a basic fragment web.xml file. This is assuming that the fragment web.xml file will be required.
2.5 Deployment Descriptor
Since the web.xml file will be optional in JEE 6 the web project deployment descriptor support should be similar to the enterprise beans deployment descriptor. By matching the behavior as the enterprise bean deployment descriptor the web project will have a consistent look and feel. For JEE 5 the enterprise bean deployment descriptor editor is a plain XML editor.
Therefore the web project should use a plain xml editor for the deployment descriptor when the server is JEE 6 compatable. Otherwise the old multiview editors should be used. There are a number of reasons for this change.
- Since the deployment descriptor is now optional it most likely will not be used that often. Annotations will most likely be used instead of the deployment descriptor.
- The deployment descriptor information is now bigger than the single web.xml file. The deployment descriptor editor should now include information that is in the deployment descriptor fragments as well as the annotated classes.
It would be best to update both the enterprise beans and web deployment descriptor editors to support the multifile nature of the deployment descriptor, but not in the NB 7 timeframe.
Priority: P1
2.5.1 Code completion
Trivial to implement in xml editor.
2.5.2 Hints
If hints are supported, this might be a good middle ground solution between a "raw xml" editor and a complete multiview implementation.
Priority: P3
2.6 Web Beans
WebBeans Definition by Gavin King:
- Web Beans is a component model that is compatible with technologies in both tiers. Web Beans integrates with both JSF and EJB3, allowing an EJB3 session bean to act as a JSF managed bean, thus unifying the two component models. Additionally, Web Beans provides a conversation model andpersistence context management, thereby solving state management problems and optimistic transaction management problems that affect JSF and JPA. In sum, Web Beans makes it much easier to build Java EE web applications which access the database via JPA.
Basically WebBeans will be another heavily annotated java source file.
Priority: P3
Notes: Candidate for the update center
2.6.1 Requires a new icon
A new icon will be required to support the data object type.
2.6.2 Create a new file wizard
Since this will be a new file type, a new wizard will be required to create the new file.
2.6.3 Create a Web Beans node under the web project
The new Web Beans node should behave similar to the Enterprise Beans node under the EJB module.
Priority: P5
3 Server Requirements
3.1 Able to query Embedded Containers are supported
An API is needed to be able to test if the server supports embedded containers.
3.2 Able to retrieve the embedded container jar
An API is needed to retrieve the embedded container jar. The jar will be needed to be added to the classpath for unit test as well as for executing beans.
3.3 Able to retrieve the server version
An API will be required to check the application servers version.
3.4 installed framework queries
3.5 supported versus installed
4 External Dependencies
The following is a list of dependencies that the Java Web Team has on other teams and products.
4.1 Finalization of the JEE 6 Specification
Since the JEE 6 specification is still in draft it is not clear that the JEE 6 specification will be finialized in time to for the NetBeans 7 release. Therefore plans must be in place to handle this possibility. There are a number of possible solutions if this was to occur. However we will need to decide on the approach soon rather than later.
- Make the support not visible unless the server support JEE 6. The problem with the approach is what happens if the specification changes from the time we ship to the time the specification is finalized. One answer is that we make the required changes and put the changes modules on the update center. However the incorrect version will be still be visible and there can be used by the user.
- Comment out the code that makes JEE 6 features visible. We could then uncomment the code when the specificaition is ready and fix any area that was changed in the specification. Once the JEE 6 support is complete we can put the affect modules on the update center. This has a possibility of making the code harder to maintain until the features are able to be shipped.
- Develop the JEE 6 features on a branch. Once the specification is ready merge the changes into the trunk and put the effected modules on the update center. This will be a maintence problem since all of the bug fixes will have to be integrated into both the trunk as well as the branch.
- Refactor the code to allow the JEE 6 to be plugged into the existing code base. By adding the ability to plug in the support for a specific JEE version will free us from having about the ship date of JEE 6. We will also benefit from this architecture in future releases of the JEE specification. Basically download and install the new specification plugin modules. However refactoring may take more time implement the required features for the current release.
Decision is to enable the features if target server is Java EE 6. For now, none of the Java EE 6 features will be enabled unless Glassfish V3 is installed since that will be only implementation of EE 6 by NetBeans 7 timeframe. We will do all the work in trunk.
6 Unclear Server Requirements
The following areas are JEE goals/features that have very little documentation. It is unclear if these are areas that will effect NetBeans Projects or will only be accessed via the server. If these features are only accessed via the server's admin console should be enough to support these features.
6.1 Servers can be more dynamic
6.1.1 need an api to check if a server can be configured "on the fly" and and api to trigger that reconfig
6.2 Profile Support
Profiles support definition according to the JEE Speicfication (JSR 316)
- To refocus the Java EE platform on particular classes of developers and applications, we propose the introduction of Java EE platform Profiles. Profiles will reference the Java EE platform, as defined by the JCP process, and may include a subset of Java EE platform technologies, additional JCP technologies not part of the base Java EE platform, or both. In addition to defining the base Java EE platform, this specification will define the rules for referencing Java EE platform technologies in Java EE Profiles.
At this time it is not know whether the profiles will only be on the server side or if applications must specify the profile that is required to support the application. If this is completly on the server side then nothing is required on the web project side. However if the applications configuration must specify the configuration (which I believe it will have to), then changes will be required.
Priority: P1
- New File wizard should not show file types not in profile
6.3 Extensibility Support
Extensibility support definition according to the JEE Speicfication (JSR 316)
- It would not be appropriate for the Java EE platform to grow without bound to include all the interesting and useful technologies desired by web and enterprise application developers. Instead, we believe it is desirable to enable more of these technologies to cleanly layer on or plug in to Java EE application servers. By adding more extensibility points and more service provider interfaces, these other technologies can plug in to platform implementations cleanly and efficiently, and be just as easy to use for developers as the facilities that are built into the platform.
At this time it is not known whether the extensibility will only be on the server side or if applications must specify the configuration requirements. For example does the application have to specify that the basic web profile is required plus spring and hibernate. If this is completly on the server side then nothing is required on the web project side. However if the applications configuration must specify the configuration (which I believe it will have to), then changes will be required.
this is may be related to the library manager and the plugin
Priority: P3
