Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [ecf-dev] RE: ecf-dev Digest, Vol 35, Issue 19 
Hi Dicky,

Dicky Johan wrote:

Scott,
Thanks for the reply, yes, if we can create a decent provider, will
definitely share the code. For the datashare API, I notice the difference is that it is actually 
creating channels and sending bytes, but I think in our case, maybe it makes
more sense to send serializable objects
There are some things to be aware of here (if you want to serialize and send/receive objects). First, you should decide whether you want to serialize/deserialize you objects in app code or have it done by the transport. For example, the docshare plugin, uses datashare, and serializes/deserializes objects *within the docshare plugin code*...that is, in the application code. There is an abstract super class for all docshare messages: 

http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.ecf/plugins/org.eclipse.ecf.docshare/src/org/eclipse/ecf/internal/provisional/docshare/messages/Message.java?root=Technology_Project&view=log
that has the serialize/deserialize methods to serialize/deserialize the Message subclass instances to and from byte arrays.
Now you may be wondering, why do this? Why not use the shared object API or the remote services API to serialize/deserialize objects? You can/may do that also, but there is a subtle issue here, and that is the OSGi-classloading and object (de)-serialization. For history, see this old bug...which was one of the motivators (not the only one) for the Equinox buddy classloading mechanism: 

https://bugs.eclipse.org/bugs/show_bug.cgi?id=87775
For explanation, let's say class A is serialized and sent by S, then received by receiver R: 

S -- A --> R
The code in receiver R that receives and processes the message must load A. Now if the deserialization code is in ECF (i.e. in a provider that implements the ECF shared object and/or remote services API), then the ECF code must be able to load class A...otherwise a classnotfound exception will be generated, and the app-level code on R will not receive the object send by S. But this can be a problem, because A may/probably was declared in a non-ECF bundle (A1), and the ECF code on R will *not typically be able to see class A in the application*. Buddy classloading can/does come to the rescue here, because with the buddy classloading mechanism the provider's classloader can 'see' into A1's set of *exported* classes, and load the class when needed to complete the deserialization. But the buddy classloading is Equinox specific as you may know.
But, notice that OSGi/buddy classloading puts the requirement on A1 to *export* the classes that are serialized. It is easy to not do forget about doing the export, and it makes life very difficult, as debugging these situations can be a challenge. This is one area where tooling might help (i.e. add warnings if Serializable classes are not exported...maybe it already does this).
So in any event, there is some utility in using the datashare API and doing your own app-level serialization/deserialization. It's not at all complex code to write (i.e. see Message class above). OTOH, remote services in particular and hidden serialization in general is convenient for some things. 


, would that be using the remote
services API? We would be using the CallAsync() function call right?


Yes, you may/can use any of the methods on IRemoteService:

http://www.eclipse.org/ecf/org.eclipse.ecf.docs/api/org/eclipse/ecf/remoteservice/IRemoteService.html
which is appropriate/desirable is...IMHO...dependent upon application-level requirements wrt responsiveness and other things. 


Also, I think you mentioned that you can run the ActiveMQ in a standalone
mode with the IApplication, is there any documentation on how to go about
doing so?
Not yet...I will try to get to that. The IApplication, however, is defined in class 

org.eclipse.ecf.provider.jms.activemq.application.ActiveMQJMSServer

in org.eclipse.ecf.provider.jms.activemq plugin at ecf1.osuosl.org.
Here is the IApplication declaration (so you can see the application id). So basically you can start the server by using the application id: org.eclipse.ecf.provider.jms.ActiveMQServer. 

Thanks,

Scott
---------IApplication declaration in plugin.xml of org.eclipse.ecf.provider.jms.activemq plugin 

  <extension
        id="org.eclipse.ecf.provider.jms.ActiveMQServer"
        name="ECF Generic Server Application - JMS (ActiveMQ)"
        point="org.eclipse.core.runtime.applications">
     <application
           thread="main"
           visible="true">
        <run
class="org.eclipse.ecf.provider.jms.activemq.application.ActiveMQJMSServer"> 
        </run>
     </application>
  </extension>


Thanks,
Dicky Johan

-----Original Message-----
From: ecf-dev-bounces@xxxxxxxxxxx [mailto:ecf-dev-bounces@xxxxxxxxxxx] On
Behalf Of ecf-dev-request@xxxxxxxxxxx
Sent: Wednesday, June 25, 2008 11:00 PM
To: ecf-dev@xxxxxxxxxxx
Subject: ecf-dev Digest, Vol 35, Issue 19

Send ecf-dev mailing list submissions to
	ecf-dev@xxxxxxxxxxx

To subscribe or unsubscribe via the World Wide Web, visit
	https://dev.eclipse.org/mailman/listinfo/ecf-dev
or, via email, send a message with subject or body 'help' to
	ecf-dev-request@xxxxxxxxxxx

You can reach the person managing the list at
	ecf-dev-owner@xxxxxxxxxxx

When replying, please edit your Subject line so it is more specific
than "Re: Contents of ecf-dev digest..."


Today's Topics:

   1. sending messages over JMS (Dicky Johan)
   2. Re: sending messages over JMS (Scott Lewis)


----------------------------------------------------------------------

Message: 1
Date: Wed, 25 Jun 2008 00:47:46 +0800
From: "Dicky Johan" <dickyjohan@xxxxxxxxx>
Subject: [ecf-dev] sending messages over JMS
To: ecf-dev@xxxxxxxxxxx
Message-ID:
	<d68025350806240947s60320cfbnd8a302f74bb1f7f8@xxxxxxxxxxxxxx>
Content-Type: text/plain; charset="iso-8859-1"

Hi,
This ECF is really great stuff, but I am still a bit lost in all the
concepts. We are trying to send messages to different instant messenging
providers over JMS. I am assuming that ECF is designed in such a way that we
can connect to a JMS provider and send a message, of which itself will
connect to another ECF provider (in this case, the instant messenger), to
send out the message.
Unfortunately, I cannot find any sample code for me to get started on this.
I see a SharedObject concept, but how do everything tie together? What would
be great is if someone can show a sample of how to send a message to a ECF
provider via a JMS ECF provider. Does anyone have any clue on this?
I am also assuming that with the ECF provider concept, we can actually
create custom provider for SMS gateways and also SMTP gateways for emails,
right?

Regards,
Dicky Johan
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
https://dev.eclipse.org/mailman/private/ecf-dev/attachments/20080624/d4c318f
6/attachment.html

------------------------------

Message: 2
Date: Tue, 24 Jun 2008 10:29:38 -0700
From: Scott Lewis <slewis@xxxxxxxxxxxxx>
Subject: Re: [ecf-dev] sending messages over JMS
To: "Eclipse Communication Framework (ECF) developer mailing list."
	<ecf-dev@xxxxxxxxxxx>
Message-ID: <48612F02.4040304@xxxxxxxxxxxxx>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

Hi Dicky,

Dicky Johan wrote:

Hi,
This ECF is really great stuff, but I am still a bit lost in all the concepts. We are trying to send messages to different instant messenging providers over JMS. I am assuming that ECF is designed in such a way that we can connect to a JMS provider and send a message, of which itself will connect to another ECF provider (in this case, the instant messenger), to send out the message. Unfortunately, I cannot find any sample code for me to get started on this. I see a SharedObject concept, but how do everything tie together? What would be great is if someone can show a sample of how to send a message to a ECF provider via a JMS ECF provider. Does anyone have any clue on this?
Yes :). There is/are test code for the JMS activemq and weblogic providers, these are on CVS server at http://ecf1.osuosl.org, in the tests module, in the 

org.eclipse.ecf.tests.provider.jms
org.eclipse.ecf.tests.provider.jms.activemq
org.eclipse.ecf.tests.provider.jms.weblogic

test projects.
The test code that's there now basically tests running ECF remote services over the two JMS providers. You would/will probably be more interested in using the ECF datashare API (an API for creating asynchronous messaging channels) although you might also be interested in remote services API. If you are able/willing, we would love to have some additional tests of the JMS providers that extend the dev.eclipse.org:/cvsroot/technology/org.eclipse.ecf/tests/org.eclipse.ecf.te sts.datashare test plugin...but we don't yet have that...sorry. On the up side, the datashare API should be already supported with the JMS providers (as both datashare and remote services are based upon the shared object API).
I will answer any questions you have, and we can use this as an opportunity to document things further and create more example and test code.
I am also assuming that with the ECF provider concept, we can actually create custom provider for SMS gateways and also SMTP gateways for emails, right?
Yes, of course. In fact if you actually do this, I would encourage you to consider sharing the work with the ECF community. 

You might be interested in the 'trivial provider' at
/cvsroot/technology/org.eclipse.ecf/examples/plugins/org.eclipse.ecf.example 
s.provider.trivial

Here's the cvs browse link:

http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.ecf/examples/plugins/or
g.eclipse.ecf.examples.provider.trivial/?root=Technology_Project

Thanks,

Scott




------------------------------

_______________________________________________
ecf-dev mailing list
ecf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/ecf-dev


End of ecf-dev Digest, Vol 35, Issue 19
***************************************

_______________________________________________
ecf-dev mailing list
ecf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/ecf-dev

Back to the top