You exact scenario still isn't clear to me, even after the lengthy
description. Sorry. :-)
I don't have much experience in using RMI with OSGi.
When you unpack your message in the Device class from the bundle, how
does the bundle have access to the DevicePositionMessage? Does it import
it? If so, to which provider is it wired?
For JMS to unpack the message, it must have access to the
DevicePositionMessage too. Perhaps it loads it from the wire? It is
likely that JMS is not getting the class from the same place as your
bundle, thus your bundle thinks it is not a DevicePositionMessage, when
it really is, but it was loaded from a different class loader, which
makes them incompatible.
The trick would be to get JMS to unpack with your bundle's class loader.
I don't know enough about RMI to tell you how to do this.
-> richard
Garrett Headley wrote:
This sort of relates to a previous post where a user
pointed me in the direction of looking at class
loaders, though I still have some problems.
I am working on a host application where I would like
to be able to include plugins for monitoring sensors.
The host application uses JMS and ActiveMQ to
communicate between modules from the hardware layer to
the client GUI. However, I'm hiding the JMS layer
from the plugin developer by having him/her extend
classes that do the actual message sending
(ObjectMessage). Also, the Serial Port services have
been written as an OSGi module also.
The device module plugin contains classes for parsing
the data from the comm port, framing the data to go
out the comm port, creating a client and server side
device representation, and the gui classes for display
of data. The SerialPort module is responsible for
listening for the device plugin being started by
Felix, and then loading the parser from that bundle,
by calling bundle.loadClass(). Great. The
DeviceParser creates a POJO message object, say,
DevicePositionMessage which implements MessageI (from
the host application), and then calls the abstract
class function sendMessage, where the host will send
the message using JMS to the client/GUI side.
Now, the client & GUI classes are loaded from the host
by listening for bundles started by Felix, and
instances are created when JMS messages are received
in the similar manner... bundle.loadClass(). However,
when the message is unpacked in the Device class (from
the Bundle), it does not register as being an
instanceof DevicePositionMessage, but it does register
as being an instanceof MessageI.
I thought I had a solution to the issue by loading all
of the bundle's classes with the AppClassLoader,
calling bundle.getClass.getClassLoader.loadClass().
Which, actually resulted in the messages being
unpacked in such a way that the check of instanceof
DevicePositionMessage was true. But, unless I
actually declare the plugin JAR file as being a
dependency of the host application, I will get
ClassNotFound exceptions. And the whole point is to
be able to just drop the plugin JAR files into a
directory and have them be loaded dynamically.
So, kind of a long explanation, but I was trying to be
thorough. I have a bit of a difficulty accessing this
list from work... if anyone wants to ask for more info
offline, (and I can always repost the solution later),
you can try my work email, headlegc AT nv DOT doe DOT
gov.
Thanks for any help,
Garrett
____________________________________________________________________________________
Be a better friend, newshound, and
know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
