04147: | OW Shell: CD into directory of Launcher process causes NullPointerException |
Category: Component
Status: ClosedSeverity: MEDIUM
Reported against release: 0.8
Fixed in release: 0.9
PROBLEM:When the Launcher demo process is started in the Openwings shell, if
the user attempts to "cd" into the directory for that launcher process,
a NullPointerException occurs:
(shell output)
.
.
.
PROCESSES:
Image_im-57065505_11b4450c_b0d5e926_3c51e8e3
Image_im-765b6693_b84a4dab_9bcca498_4df6cbc2
Launcher_im-3f42c132_c0d04b03_96a3aff7_8225ef31
installer-95094c5e_962644ed_ba63d58b_b00c5c00
jakarta-tomcat-3.2.1-7fa5294f_8789471b_b27f8ede_dddf0f2a
jini-1.1-f83e83c8_57e94393_b1cecfdb_0ceda8e1
Openwings@root\AZ25-JP05Q01-137.162.171.58\> cd
Launcher_im-3f42c132_c0d04b03_96
a3aff7_8225ef31
Exception in thread "main" java.lang.NullPointerException
at
net.openwings.component.utilities.ServiceDescriptor.getName
(ServiceDescriptor.java:44)
at
com.mot.openwings.context.ui.shell.OpenwingsEntityProcess.updateMyServic
es(OpenwingsEntityProcess.java:183)
at
com.mot.openwings.context.ui.shell.OpenwingsEntityProcess.updateMyDescen
dants(OpenwingsEntityProcess.java:67)
at
com.mot.openwings.context.ui.shell.Shell.setPath(Shell.java:368)
at
com.mot.openwings.context.ui.shell.CommandCd.processOneArg
(CommandCd.java:162)
at
com.mot.openwings.context.ui.shell.CommandCd.process(CommandCd.java:102)
at
com.mot.openwings.context.ui.shell.Shell.shellMode(Shell.java:254)
at
com.mot.openwings.context.ui.shell.Shell.run(Shell.java:119)
at
com.mot.openwings.context.ui.shell.Shell.main(Shell.java:451)ANALYSIS:The problem is that an incorrect ServiceDescriptor is being returned by
the management bean Component Services provides, with serviceInterface
set to null. Calling ServiceDescriptor.getName() just does a
serviceInterface.toString(), that's the line that gets NullPointer
exception.
There is an error in how Component Services builds ServiceDescriptors
for used services. The Launcher is the only demo component that uses
null for its requested service interface, because it is interested in
any service for which it can obtain a user interface.
For used services, Component Services considers the interface of the
service to be the interface you asked for. Since the component asked
for "null", Component Services considers the interface of the services
located to be "null", and puts that right into the ServiceDescriptor.
There are some issues that need to be resolved in order to fix this
defect properly:
A service object may actually implement multiple interfaces. Suppose
there is an interface B which extends interface A. If a user asks
for "A" services, they may get "B" services as well. When we build up a
ServiceDescriptor for the used service and it turns out to be a "B",
which interface should we report - "A" or "B"?
That is a simpler case. The harder case is, if the user asks for all
services (serviceInterface = null), and they end up using a service
object that implements multiple interfaces, which do we report? In the
interface-extension scenario, I'd argue for reporting the lowest level
interface (in our example, that would be "B"). However, suppose that
the actual service object also implemented another interface "C",
unrelated to A or B. Then, we really can't just pick one interface to
report. Since the user wasn't specific in what they wanted, we have no
idea whether to report it as a "B" or a "C".
Note: The case mentioned above is not a typical case, and it's better
to have a partial solution than none at all. Therefore, to fix this
defect, the first legal service interface detected will be chosen.
Because of the way java.lang.Class.getInterfaces is implemented, lower
level interfaces will occur first in the list of interfaces obtained
from the class of a service object. |
