Hi Scott,
I'm doing some due diligence on this and will get back to you
directly.
Shaun
On 30/9/2010 4:10 PM, Scott Lewis wrote:
Hi
Shaun,
On 9/30/2010 11:43 AM, Shaun Smith wrote:
<stuff deleted>
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.
Yeah, that was my thinking.
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.
Right. Actually, where I'm headed with this is to have a
persisted implementation of distributed event admin...i.e. see:
http://wiki.eclipse.org/Distributed_EventAdmin_Service
In this model, the idea would be to persist all instances of the
Event class (and/or instances application-specific subclasses of
Event). The fq name of the Event class is:
org.osgi.service.event.Event, and in Equinox it's in
org.eclipse.osgi.services bundle.
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?
Unfortunately, no. ActiveMQ has got so many dependencies (e.g. on
other apache libs, etc) that we've been daunted in even proposing
to have it go through the IP approval process. Because of this,
ECF does not have it's JMS/ActiveMQ provider bundle in the
eclipse.org repository. Rather, we've got a github repository for
this code here:
http://github.com/ECF
The projects I am talking about are currently in the JMS public
repository. As you can see we have other codebases there as
well...mostly because of dependencies on other libs that cannot go
through the EF process (e.g. are gpl, or lgpl, etc).
So I/we can/could add a new project for this persistence adapter
to this JMS repository...and I will do so if/when you say. Of
course we can/would make you (and others) able to modify
things/give your github account access. Before I do this
though...will this be OK with you and employer...and if so do you
already have a project (that I could add)...or should I create
one? (and if so...in what namespace?).
Thanks Shaun.
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
|
