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
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
I realize that some may not like the way this exploits the JavaBean
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
"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
It makes more sense for these to be extended with 'plain old'
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
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
but is it satisfactory?
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.