Since there can be three different class loaders in play (1), 1) the service's,
2) the UIDescriptor's and 3) the clients classpath, we have to account for this
in the end. Many times the ServiceItem.service object and the UIDescriptor(s)
share the same codebase so there will only be two class
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 su
Will do it in when I'm back at my dev machine.
-- Calum
Sent from my iPhone
On 14 Feb 2011, at 20:07, Peter Firmstone wrote:
> Well spotted Calum,
>
> Can you raise a Jira and link it to River-292?
>
> Cheers,
>
> Peter.
>
> Calum Shaw-Mackay wrote:
>> All -
>>
>> I believe this may be ti
Well spotted Calum,
Can you raise a Jira and link it to River-292?
Cheers,
Peter.
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 rathe
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 uiF
