Hi Calum,
The ServiceUI support implemented as part of RIVER-292 is indeed very
basic. I just needed a tool to debug GUIs associated with Jini services
and the commercial Inca-X browser I was using at that time didn't allow
me to do that in a satisfying way.
As you found out there is only support for the JFrameFactory, because
that was what I needed at that time, but it won't be that hard to
support the other UI factory interfaces listed in the ServiceUI
specification and to honor the attributes associated with the
UIDescriptor as well as the role.
On 14/02/2011 15:34, Calum Shaw-Mackay wrote:
All -
I believe this may be tied to RIVER-292, but I'll just outline the issue
The UIDescriptor is being asked to load the UIFactory via the current
thread's Context Class Loader rather than the
classloader that the service itself is being loaded with.
Thus the code:
try {
JFrameFactory uiFactory = (JFrameFactory)
uiDescriptor.getUIFactory(Thread.currentThread().getContextClassLoader());
JFrame frame = uiFactory.getJFrame(item);
frame.validate();
frame.setVisible(true);
}
should be
try {
JFrameFactory uiFactory = (JFrameFactory)
uiDescriptor.getUIFactory(item.service.getClass().getClassLoader());
JFrame frame = uiFactory.getJFrame(item);
frame.validate();
frame.setVisible(true);
}
In the subject you mention the word 'bug', did you really run into a
problem or did you notice the code above doesn't match the code in the
ServiceUI specification?
The UIDescriptor will only set the thread context class loader to the
class loader passed in while unmarshalling the marshalled UI factory, so
it ain't as bad as you make it sound ;-). Although your code snippet
should be used, the code currently in place should give no problems in
case the UI factory itself originates from the same codebase as the
service (ServiceItem). In case the UIFactory is coming from a different
codebase there will be impact though.
Regards,
--
Mark Brouwer
