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.

Bug 37792

Summary: Allow more flexibility and extensibility of the plugin UI
Product: serverplugins Reporter: Petr Jiricka <pjiricka>
Component: InfrastructureAssignee: Nam Nguyen <nnguyen>
Status: RESOLVED FIXED    
Severity: blocker CC: nnguyen, pbuzek, vkraemer
Priority: P1    
Version: 3.x   
Hardware: All   
OS: All   
Issue Type: DEFECT Exception Reporter:

Description Petr Jiricka 2003-12-05 14:01:33 UTC
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.
Comment 1 Petr Jiricka 2003-12-05 14:07:55 UTC
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.

Comment 2 Petr Jiricka 2003-12-05 14:09:32 UTC
Sorry, the last part does not belong to this issue.
Comment 3 Petr Jiricka 2003-12-05 17:12:19 UTC
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."
Comment 4 Nam Nguyen 2003-12-05 17:15:39 UTC
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.
Comment 5 Vince Kraemer 2003-12-05 17:59:01 UTC
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.
Comment 6 Nam Nguyen 2003-12-05 18:11:08 UTC
The InstanceNode is actually represent both jsr88 DeploymentManager
and jsr77 Management objects.  JMX MbeanInfo will be used.
Comment 7 Unknown 2003-12-09 00:21:35 UTC
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.

Comment 8 Nam Nguyen 2003-12-09 00:47:10 UTC
The management node will be decorated as java BeanInfo if the
MBeanInfo returned by Management.getMBeanInfo(ObjectName object) is
also implements BeanInfo.
Comment 9 Nam Nguyen 2003-12-09 18:02:24 UTC
(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

Comment 10 Nam Nguyen 2003-12-22 11:06:49 UTC
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.