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

[Scott Lewis <slewis@xxxxxxxxxxxxx>]

Hi Shaun,

On 9/30/2010 7:56 AM, Shaun Smith wrote:

Hi Scott,

On 30/9/2010 10:43 AM, Scott Lewis wrote:

BTW, is it possible with JPA/EclipseLink to define the mapping in java code at runtime?  (you can probably tell I'm not big on JPA details yet).   With pointers I'll investigate.

There isn't a JPA runtime API for defining mappings; they are declared either through XML or annotations.  That's not to say it isn't possible using EclipseLink's API but it isn't something you can easily do out of the box.  But in this case I would think that XML mapping would suffice given the binary nature of the ActiveMQ classes.

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.

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.

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 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?).

Does this make sense?

Thanks,

Scott