EnterpriseJava70

(Difference between revisions)
(Web Services)
(Web Services)
Line 125: Line 125:
'''EE4.3.4''' REST: unintrusive REST support [http://netbeans.org/bugzilla/show_bug.cgi?id=168154 168154]
'''EE4.3.4''' REST: unintrusive REST support [http://netbeans.org/bugzilla/show_bug.cgi?id=168154 168154]
-
'''EE4.3.5''' REST: extend Test Resource capability [http://netbeans.org/bugzilla/show_bug.cgi?id=187945 187945]
+
'''EE4.3.5''' REST: extend Test Resource capability [http://netbeans.org/bugzilla/show_bug.cgi?id=187945 187945], [http://netbeans.org/bugzilla/show_bug.cgi?id=159073 159073]
=== Other EE ===
=== Other EE ===

Revision as of 13:04, 22 June 2010

J2EE Development Simplified in NB 6.9.NEXT

Author: DavidKonecny
Version: draft 0.0.4

Contents


Motto: Everything just works

Not according to feature coverage matrix but on real life usecases spanning several EE specifications. For example user is developing a service which can be used via web browser or REST API and the service stores some data in a database and communicates with some other web services and EJBs. The IDE modular architecture and fact that separate Java EE specification are implemented by different teams should not have any impact on user's experience. Features from different modules should seamlessly cooperate and complement each other.

Another aspect to pay attention to in this release is how well features work outside of compile-debug cycle of single user. For example an IDE feature can generate a unit test for an EJB and such test can be executed. But can such project be checked into versioning control system and just run if checked out by a continual builder or different team member? how will an embeddable EJB container be provided? Features should be look at in broader scope and wherever applicable they should just work.

Following chapters will discuss individual IDE areas in detail.

Maven and Ant

In theory Maven and Ant are just build harnesses and therefore user should not notice any difference during daily coding in IDE regardless of what build system is used.

On the other hand it is not practical nor desirable to abstract IDE user from build harness. Ant and Maven are different and have their own specific features that should stay accessible to user. There is also no practical need for example to enable interproject dependencies between Ant and Maven - possible but not a good practice IDE should suggest to users.

However, most of the IDE features should work regardless of underlying build system.

Maven

EE1.1: improve handling of server selection in EE Maven project types

EE1.2: resolve problem with running unit tests in Maven EE 6 project - stripped Java EE 6 jars are unusable

EE1.3: make sure packaging of EE Maven projects is correct (EJB jars are not packaged in WAR; libraries are stored in EAR/lib; etc.)

EE1.4: make sure deployment/debugging of EE Maven projects works as in Ant based projects (AppClient on GFv3; Weblogic; standalone EJB/AppClient modules deploytment; etc.)

EE1.5: EJB embeddable container support works (in different server scenarios)

EE1.6: support for annotation processing and JPA annotation processor

EE1.7: Deploy on Save works in EAR project

EE1.8: misc small issues:

  • when server deployment fails Maven does not report it and stays in "deploying..." mode
  • remote interface project selector should not list Ant based projects for Maven project - Maven cannot have dependency on Ant based project
  • EAR Maven should not have sources, compilation, etc. (in project logical view, proj props, ...)
  • JSF wizard panel should pre-select JSF version according to server (if available)
  • sources panel in project properties should list web application folder if one is present
  • in proj properties I cannot see which fields are editable and which are readonly. Perhaps problem of look and feel. Eg. fields in General panel are editable, but fields in Sources are not


Ant

tbd

GlassFish and Weblogic

]Similar case like Ant and Maven. Most of the time the user should be abstracted from the underlying server and all IDE features should just work regardless of server. But there will always be differences between the servers and user should have access to these server specific features.

GlassFish

See GlassFish 3.1 planning document

Weblogic

EE2.1: Weblogic server libraries

  • P1: deployment
  • P1: classpath handling
  • P2: sharability

EE2.2: Unit tests for Weblogic plugin

EE2.3: Enhance Weblogic support

  • P1: deploy on save
  • P2: enable EE 6 support for upcoming Weblogic 11
  • P3: server properties configuration dialog
  • P3: link to source from output

EE2.4: Web Services support

  • P3: support JSR109 for WebLogic 187597,187599
  • P3: support WS Tester for WebLogic 187598
  • P3: support JAX-WS Client for WebLogic 187931
  • P3: support WS from WSDL for WebLogic 187932

EE2.5: NetBeans and WebLogic co-bundle

EE2.6: P4: WebLogic deployment descriptors

Deployment

All common deployment scenarios must work. Regardless of target server - for example both Glassfish and Weblogic have their own proprietary deployment descriptor fiiles. Regardless of whether EE Application or EE Module is being deployed - for example each server is handling deployment of standalone EE modules and their required libraries differently. Regardless of EE technology being used - for example Weblogic requires Weblogic specific version of JSF libraries while GlassFish not. Files being deployed should follow EE specification requirements or best practice - automaticaly package required libraries which are not EE module into EAR's lib directory; place remote interfaces of EJBs into dedicated reusable library project.

EE3.1: fix standalone EE Module deployment

EE3.2: GlassFish vs Weblogic deployment (eg. appclient deployment to GlassFish is hardcoded in AC project type)

EE3.3: project sharability and server sharability (can it be improved?)

Richer EE/Web support

JSF

EE4.1.1: ADF components

EE4.1.2: Trinidad components

CDI

EE4.2.1: refactorings aware beans.xml

EE4.2.2: class code completion in beans.xml

EE4.2.3: add support for find Event Producer/find all Observers (similar to the current support "Go to Injectable/Inspect Injectables"; perhaps already available?)

EE4.2.4: support for portable extensions (wizards, ambiguous and unsatisfied dependencies checks, etc.)

EE4.2.5 dependency graph visualization

Web Services

EE4.3.1 SOAP: unintrusive JAX-WS support 186299

EE4.3.2 SOAP: support for HTTP GET/POST bindings 174326

EE4.3.3 REST: JAXB annotations in Entity classes 181161

EE4.3.4 REST: unintrusive REST support 168154

EE4.3.5 REST: extend Test Resource capability 187945, 159073

Other EE

EE4.4: Bean Validation support

EE4.5: JSP editor architecture improvements

More helpful IDE

EE5.1: add intelligent hints/TODOs

EE5.2: EE refactorings

EE5.3: new EE samples/EE tutorials

Improve development of DB based Web Applications

EE6.1: JPA wizards: faster reading of tables by filtering by name

EE6.2: Add support (recognize) for more jpa2.0 providers

EE6.3: Improve update/recreate/new for entity from db

  • Better update support (fix issues and support update for more elements like id classes, column types etc), currently only new columns creation works properly.
  • Usability - recreate all, update all, new all buttons, filter 'create new only' in 'add all')

EE6.4: Recognize/support derived ids, and may be as subtask add usage in entity from db generation.

EE6.X: Continue on work started in http://wiki.netbeans.org/EnterpriseJava69

Testability

EE7.1: embeddable EJB testing works in all scenarios

EE7.2: testing of CDI based code works out of box

Other ideas

  • OSGi webapps
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