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
|