Re: [eclipselink-users] EclipseLink as ActiveMQ persistence adapter?

[Shaun Smith <shaun.smith@xxxxxxxxxx>]

On 30/9/2010 1:46 PM, Scott Lewis wrote:

Send me a pointer to the classes that need persisting?

I don't have them fully identified yet...it will include some ECF classes...i.e. from the ECF generic provider (classes in org.eclipse.ecf.provider bundle), and some classes from ECF's JMS/ActiveMQ provider (at github)...as well as some app-level classes that I haven't yet identified.

Ok.

One thing I would like to do (and need you to tell me if this is actually possible)...is to avoid persisting all the ECF classes...and only persist the app-level instances.  What I mean is that we have a layered structure like this:

App
  |
V
ECF Provider (uses/depends upon ActiveMQ/JMS)
|
V
ActiveMQ

When the app sends a message (using ECF messaging API), the ECF provider wraps the app-level message with it's own message instance/class (e.g. ECFMessage(appmsg)).  And then sends it via the JMS ObjectMessage.

What I would ultimately like to accomplish with this persistence adapter (if possible), would be to 'unwrap' the message (take the payload out of ECFMessage, for example), and persist only *that*...without persisting the ECFMessage instance that wraps the app-level message.  That would avoid having to define JPA mappings for all the ECF provider classes (e.g. ECFMessage), and allow concentration on persisting (and reviving/retrieving) only the app-level classes.

Do you think this is doable?  Upon some thought I suppose it would have to be a 'feature' of the persistence adapter...i.e. to unwrap these messages.

I don't see why not.  I assume the wrapped objects are unaware of and have no dependencies on the wrapper so they should define a nice tidy object graph.  In fact I think this makes the most sense.  An ECF/EclipseLink PersistenceAdapter could wrap/unwrap as necessary if there's no need to persist any of the data contained by any of the wrappers.

For the EclipseLink impl of ActiveMQ persistence adapter let's do this..maybe you could just make up a single, relatively simple, class for JPA mapping...and we can both attempt to understand the ActiveMQ persistence adapter API better than we do now. 

I think the class interacting with JPA is the PersistenceAdapter itself who's API doesn't look that complicated.  And I assume that we're free to design a database schema that suits us so my primary interest is in figuring out what domain model classes we need to persist and their relationships.

I feel I need to understand the API better than I do now...and so I'll look at the other existing persistence adapters as well as the code that you come up with that uses EclipseLink to implement the persistence adapter...as long as you are willing/able to share it with me as it's being developed (e.g. through EclipseLink incubation area?...or somewhere else?).

The EclipseLink incubator may be a good choice for now.  We have a relatively light weight process to create a new component (http://wiki.eclipse.org/EclipseLink/Development/Incubation).  But given the dependencies this code will have on ActiveMQ it's probably better if it lives in ECF, which I assume already has a dependency and all the appropriate CQs in place?

    Shaun

Does this make sense?

Thanks,

Scott

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

--

Shaun Smith | Principal Product Manager
Phone: +19055023094
Oracle Server Technologies, Oracle TopLink
ORACLE Canada | 110 Matheson Boulevard West, Suite 100, Mississauga, Ontario | L5R 3P4
Oracle is committed to developing practices and products that help protect the environment