This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
Plugins should be able to add properties and actions to the server nodes. This would allow to configure some basic plugin properties, such as HTTP port, debug information (port, attach style), whether the HTTP Monitor is enabled, and (potentially) server classpath and JVM path. Or, the plugin could add actions to view/open log files and other useful actions not provided by the infrastucture. An important requirement is that the server must not be started when the user accesses this UI.
As Nam suggested that we may want to look at this (Name has already more than enough on his plate!), I am assigning this to Martin Grebac. Here's a solution suggested by Vince Kraemer: Treat the node that represents the DeploymentFactory and DeploymentManager as a JavaBean... kinda. Use the properties to create a property sheet for a node Use the methods to create menu items for a node. This would only be done IF there is a BeanInfo for the DF and/or DM class. I would like to see the netbeans specific parts lumped into j2eeserver code (not on my plate). I think there should also be a way to shortcircuit this mechanism and allow plugins to provide a Sheet and Menu to j2eeserver to decorate the nodes. This would allow the level of control that some folks would prefer. I realize that some may not like the way this exploits the JavaBean architecture. I think it would be useful though. Request for clarification [related to issue 5] I think there is a disconnect between Nam and folks working on the Tomcat plugin/jsr88 implementation. I would think that their plugin could actually provide the target list without being started. Is that possible? Feedback related to issue 8 I agree that the user should NOT have to configure the DeployableObject explicitly. I think the tool SHOULD create a DeploymentConfiguration object for stuff that it wants to deploy, though. The Jsr88 implementation's DeploymentConfiguation would be responsible for computing the "nice defaults" that Ludo alludes to.
Sorry, the last part does not belong to this issue.
Actually, this issue will be addressed differently, as suggested by George FinKlang: "There is an easier and more architecturally sound solution that is consistent with the other ServerRegistry UI. That is to show the J2eeServer MBeanInfo on the InstanceNode."
Added George's solution description: We have an infrastructure already to get server registry UI from the plugin, using MBeanInfos. Currently the InstanceNode isn't hooked up to this. We could hook this up to this infrastructure. The major requirement here is that the server not be started while accessing this. We can add a predicate in StartServer to address this requirement. We estimate about a week for this functionality.
I would think that having a way to extend the UI of the node that represents the DeploymentFactory and the DeploymentManager would be useful, too. (I am assuming that the InstanceNode that Nam referred to in the previous comment is the node that represents a Target (in jsr-88 terms). It makes more sense for these to be extended with 'plain old' BeanInfo objects.
The InstanceNode is actually represent both jsr88 DeploymentManager and jsr77 Management objects. JMX MbeanInfo will be used.
JMX Beaninfo is not enough to provide this type of info: - help id for F1 context sensitive help - status bar (and tooltip) for the selected node - copy/paste DND semantic (ascii representation,...) - Icon changes (depending on the server status) (Icon badging) I think existing APIs like BeanInfo, Nodes, BeanNodes should be used instead of defining other apis which seem to be incomplete and not netBeans aware. So JMX MbeanInfo does not provide good enough info to be user friendly in a NetBeans Tree/Explorer environment.
The management node will be decorated as java BeanInfo if the MBeanInfo returned by Management.getMBeanInfo(ObjectName object) is also implements BeanInfo.
(Add George proposal for jsr77 alternative) I think dropping support for a standard (jsr77) is a poor decision. Another option might be to create some scheme for the plugin to supply a Look for ServerNode and InstanceNode - this would be combined with the code already present to produce a compound node. This would enable us to still have jsr88-related nodes managed by the jsr88 infrastructure, but have additional stuff provided by plugin Looks. Also, in this way, children of InstanceNode could be completely supplied by the InstanceNode Look provided by the plugin, and the plugin could decline to implement ManagementMapper, or somehow disable the nodes generated from the Management info. This is a more complex scheme than just providing BeanInfos for these nodes, but is it satisfactory? --George
This issue has been resolved with support for plugin provided service: RegistryNodeFactory. Through the service plugin could provide UI nodes representing JSR-88 concepts: DeployementFactory, DeploymentManager, Target. J2eeserver module filter these node children (except for Target node), provide default menu actions, provide node merging as necessary.