J2EEServerWithoutJSR88

Revision as of 12:17, 5 November 2009 by Admin (Talk | contribs)
(diff) ← Older revision | Current revision (diff) | Newer revision → (diff)

J2EE Server Without JSR-88

Motivation

  • Arrival of Retouche - the DD change events are no longer available
  • Overhead - currently when the J2EE project is opened the DD graph is being created, wrapped by the DDBean wrapper and plug-ins register their Xpath listeners. Nothing of this is really needed.
  • Low control - currently we are eagerly trying to keep the server specific DDs up-to-date even in cases when user would not expect that. User's handmade changes in the server-specific DDs can be lost.

Supported Servers

Although there is not a NetBeans plug-in for all the servers from the list below, we should make sure that the changes to be made will not introduce a blocker for creating such a plug-in.

* italic means there is no NetBeans plug-in for this server

Types of DD changes

  • external when the IDE is running
  • external when the IDE is not running
  • handmade changes in the textual editor
  • handmade changes in the graphical editor
  • user triggered actions
  • Set context root
  • Use database
  • Create datasource
  • Call JMS
  • Send E-mail
  • Create entity beans from DB

Project-plug-in communication proposal

Proposal 1

  1. for actions like Call JMS, Use database, etc. there will be explicit calls to the plug-ins. Plug-in are expected to define all the needed resources and update the server-specific DDs respectively. This will run synchronously
  2. the target server plug-in will be notified about the handmade standard DD changes (done either in the graphical or textual editor) by a call named like ddModelChanged(). The plug-in will be then expected to check whether the server-specific DD requires update and if yes then the user should be notified about that and also should be offered to do so in some easy way. This will run asynchronously and thus lower performance shouldn't be a problem.
  3. if annotations change then the behavior between the project and the plug-in will be the same as if the standard DD changed.
  • Pros
  • Consistency in handling XML and annotation changes
  • Improved performance
  • Cons
  • Would not be consistent with how refactoring works
  • To much work

Proposal 2

  1. changes in the standard DD will be tracked by listening to the model changes
  2. DD API BaseBean model will be used instead of the JSR-88 DDBean based model
  3. annotation changes
    1. plug-in will not be notified about the annotation changes at all
    2. plug-in may be notified that model might have changed
  4. the graphical editor will have a refresh or synchronize button which will trigger refresh of the standard DD graph - merged from the XML file and annotations.
  5. plug-in will use refactoring for tracking changes like ejb renaming
  • Pros
  • Less work
  • Use of refactoring
  • Cons
  • Old problems like low control and performance overhead will remain, the effect will be, however, reduced when using Java EE 5

Use Cases

The current and the proposed new behavior

  1. Creating a new project
  • The J2eeModuleProvider.ConfigSupport.ensureConfigurationReady is called. The plug-in is expected to create and initialize its server specific DDs.
  • The plug-in will be requested to create the initial server specific DDs.
  • The J2eeModuleProvider.ConfigSupport.ensureConfigurationReady is called. The plug-in is expected to create and initialize its server specific DDs.
  1. Opening a project (the standard DD might be modified)
  • The J2eeModuleProvider.ConfigSupport.ensureConfigurationReady is called. The plug-in is expected to create and also synchronize its server specific DDs without letting the user know about it. The automatic synchronization might cause data lost in some cases. The plug-in is also expected to register its XpathListeners and to start listening to the DDBean changes.
  • The plug-in will be notified that the standard DD might have changed. The plug-in is then expected to check asynchronously whether its server-specific DDs are in sync and let the user know if they are not. The preferred way of letting the user know would be adding a task to the task list.
  • The J2eeModuleProvider.ConfigSupport.ensureConfigurationReady is called. The plug-in is expected to create and also synchronize its server specific DDs without letting the user know about it. The automatic synchronization might cause data lost in some cases. The plug-in is also expected to register its PropertyChangeListeners and to start listening to the DD model changes. From this poitnt the plug-in may be notified about the model changes caused by annotations. If needed, the plug-in should register itself in refactoring.
  1. Opening a project with missing target server
  • It is maybe just a bug but if the missing target server is AppServer then the server-specific DD support is broken, it works fine for other servers, however.
  • The server-specific DD support should not depend on a specific server instance and thus it should work the same way as for #2.
  • If the configuration support will not require having a registered instance, everything should work.
  1. Opening a project with missing target server plug-in
  • The server-specific DD support is broken.
  • The server-specific DD support will be broken. This also means that if a new target server will be set, the previous target server context path, resource definitions, etc. cannot be set for the new target server unless we introduce some kind of general resources.
  • The server-specific DD support is broken.
  1. Opening a J2EE 1.4 project with missing DD
  • The same as for #2 with an exception that the XpathListeners cannot be registered, plug-in is thus unable to listen to the DDBean changes even if the standard descriptor is created later on.
  • The same as for #2. Since the XpathListener model is not used anymore, there is no problem and everything will work fine.
  1. Switching the J2EE spec version - currently this feature is not supported
  • The plug-in is not notified of this change and thus the server-specific DDs cannot be updated appropriately
  • The plug-in may be requested to take appropriate steps.
  • An API can be added to request the plug-in to take appropriate steps.
  1. Switching the project target server
  • The old target server DeploymentConfiguration is notified that it should stop listening to the DDBean changes. The further steps are the same as for #2. In case of web projects the context path is retrieved from the previous server-specific DDs and set to the new server-specific DDs
  • The steps will be the same as for #2. In case of web projects the context path will be retrieved from the previous server-specific DDs and it will be set to the new server-specific DDs. Should we do the same for resources? Is it worth the effort?
  1. Switching the project target server to the target server of the same type
  • It behaves the same way as for #7. Unnecessary overhead
  • No need to do anything
  1. Switching the target server type
  • Right now, there is no way how to switch the target server type without switching the target server instance, except doing it by hand in the project.properties
  1. Removal of the target server
  • No need to take any special steps here.
  1. Removal of the target server plug-in
  • The target server plug-in will no longer receive any notifications.
  1. Manual creation of the standard DD after it was missing
  • The plug-in is not notified about this change and thus it cannot start listening to the DDBean changes
  • No need to take any special steps here. Notification after saving the file will take care of it.
  1. External modification of the DD when the IDE is running
  • If the external modification is accepted, the plug-in receives the DDBean change events and updates the server-specific DDs without letting the user know about it. The automatic synchronization might cause data lost in some cases.
  • No need to take any special steps here. Notification after saving the file will take care of it.
  1. Handmade changes in the textual editor
  • The plug-in received the DDBean change events and updated the server-specific DDs without letting the user know about it. The automatic synchronization might have caused data lost in some cases.
  • No need to take any special steps here. Notification after saving the file will take care of it.
  1. Undo after handmade changes in the textual editor
  • The plug-in receives the DDBean change events and updates the server-specific DDs without letting the user know about it. The automatic synchronization might cause data lost in some cases
  • No need to take any special steps here. Notification after saving the file will take care of it.
  1. Save after handmade changes in the textual editor
  • Saving the file does not trigger any event, it is not needed however.
  • After saving the file, the plug-in will be notified that it should check whether its server-specific DDs do not need to be updated.
  1. Handmade changes in the graphical editor
  • The plug-in receives the DDBean change events and updates the server-specific DDs without letting the user know about it. The automatic synchronization might cause data lost in some cases
  • No need to take any special steps, notification after saving the changes will take care of it.
  1. Undo after handmade changes in the graphical editor
  • The plug-in receives the DDBean change events and updates the server-specific DDs without letting the user know about it. The automatic synchronization might cause data lost in some cases
  • No need to take any special steps, notification after saving the changes will take care of it.
  1. Save after handmade changes in the graphical editor
  • Saving the file doesnot trigger any event, it is not needed however.
  • After saving the file, the plug-in will be notified that it should check whether its server-specific DDs do not need to be updated.
  1. Set context root
  • The plug-in set the specified value in the server-specific DD, in case of an error the client - project is not notified about it
  • The plug-in will set the specified context root value in its server-specific DDs or it will throw an exception in case of an error.
  1. Get context root
  • The plug-in returns the context path value form the server-specific DD, or null in case of an error
  • The plug-in will return the context root value from its server-specific DDs or it will throw an exception in case of an error.
  1. Use database
  • Plug-in is notified about a new resource reference in the standard DD via its XpathListener, it is, however, not possible to distinguish it from adding the resource reference manually.
  • Plug-in will be requested to update its server-specific DDs by a special call.
  1. Create new datasource
  • Plug-in is called to create the desired datasource
  • Plug-in will be called to create the desired datasource
  1. Delete a datasource
  • Are there any steps needed? If the users removes the resource definition we won't be able to undeploy this resource.
  1. Call JMS
  • Plug-in ss notified about a new resource reference in the standard DD via its XpathListener, it is, however, not possible to distinguish it from adding the resource reference manually.
  • Plug-in will be requested to update its server-specific DDs by a special call.
  1. Create new JMS resource
  • Not sure how this is done by the AppServer plug-in at this point.
  • Plug-in will be called to create the desired JMS resource
  1. Delete a JMS resource
  • Are there any steps needed? If the users removes the resource definition we won't be able to undeploy this resource.
  1. Send E-mail
  • The plug-in is notified about a new mail resource via the XpathListener. No plug-in supports this by defining the respective JNDI mapping to the server-specific DD at this point.
  • Plug-in will be requested to update its server-specific DDs by a special call.
  1. Create new mail resource
  • Creating the mail resource is not supported at this point
  • Plug-in will be called to create the desired mail resource
  1. Delete a mail resource
  • Are there any steps needed? If the users removes the resource definition we won't be able to undeploy this resource.
  1. Create entity beans from DB
  • The J2eeModuleProvider.ConfigSupport.setCMPMappingInfo() call requests the plug-in to create the CMP mapping.
  • The plug-in will be requested to create the CMP mapping
  1. Server specific DD editor is being opened during the IDE startup before the respective project is opened
  • The plug-in requests the j2eeserver to initialize the respective DeploymentConfiguration which then provides the DDBean model. This current model is pretty award since the DeploymentConfiguration can be initialized from two different places, from the devmodule (project) and from the plug-in.
  • The plug-in will request the DD model directly from the respective project
  1. Server specific DD editor is being opened during the IDE startup after the respective project was opened
  • The plug-in gets the DDBean model from the respective DeploymentConfiguration
  • The plug-in will request the DD model directly from the respective project

Important Questions

  1. Should the server-specific DD support depend on a specific server instance rather then just on a specific server type?
  • No, there is no known reason for it to be tied up with a specific server instance
  1. Does the server specific DD support require the server to be registered?
  • No, there is probably no reason for this unless some libraries from the server are required for editing the server-specific DDs. Is there such a case?
  1. Does the server specific DD support require the server to be running?
  • No, there is no known reason for it, besides starting the server just because of being able to edit the server-specific DDs would not be very user friendly.
  1. Should Use database, Call JMS and other actions survive switching of the project target server? Should the respective resources be recreated for the new target server?
  • Probably yes
  1. General resources definition?
  • Do we need to introduce something like general resources definition? What would be the pros and the cons?
  1. Do we need to add some support for fixing the JNDI name conflicts?
  • Do not know yet, this seems to be more like a deployment time problem.


-- Main.StepanHerold - 19 Oct 2006

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