Norm
Firstly, thanks very much for taking the time to comment.
Basically there is an interface "Registry". The default impl is
JDBCRegistry. If you want to back this with ORM, then the answer is that
you need to create an ORMRegistry implementation.
https://wso2.org/repos/wso2/trunk/registry/modules/core/src/main/java/org/wso2/registry/Registry.java
We always had in mind that there might be an ORM/JPA implementation, its
simply that we felt the 'basic' functionality could be implemented with
just JDBC, without much problem. Certainly, if you want to join in and
contribute an ORM Registry we'd be very happy to accept it. I think that
would also help ensure the validity of our interface definition across
multiple backends.
As regards resource associations, we have a concept in the Resource of
dependencies, which is a generic set of things that are linked. We use
this to track when changes affect associated resources. Is that
sufficient for your needs?
You can see the methods:
getDependsOn() and GetDependedOnBy()
in
https://wso2.org/repos/wso2/trunk/registry/modules/core/src/main/java/org/wso2/registry/Resource.java
Paul
Norman Barker wrote:
Hi,
I downloaded the registry release, and it works great in JBoss and I
really like the web interface so I downloaded the code as well.
I was surprised to see that it wasn't using an ORM mapper since with
simple JPA mappings you can switch between hibernate and OpenJPA
without too much of a problem (I have just ported a large project from
JBoss to WebLogic (hibernate -> OpenJPA). I also saw that this was
discussed on the list in some depth - but unfortunately it immediately
makes the registry less appealing to me and it is tempting just to use
the abdera servlet example ... What would it take to add an ORM
persistence engine (if you give me a class name I will try writing the
code).
My reasons for wanting to use ORM tools is that it would be useful to
support complex database objects (e.g. GML documents, store the XML
descriptions of the geometry as spatial geometry objects) there has
been a lot of work (and indeed I wrote the hibernate code for PostGIS)
to map these in the database and utilise the spatial index. Hibernate
criteria queries, and dialects (again for spatial functions) are very
useful. The license for hibernate as opposed to Apache is an issue,
but JPA is a specification for annotations and can port across
implementations. I am thinking that writing generic indexing services
will be a lot easier with ORM tools since the indexing service does
not have to worry about the underlying database engine.
without ORM I don't see the benefit of this implementation of the
registry as it seems to have ignored the big steps taken forward by
EJB3, take for example the container port I have just performed,
pointbase is the DB for weblogic (a major vendor!) and I can't just do
it if I am dependent on a SQL create script (well actually we probably
could), but with JPA a user wouldn't have to worry (so much).
Don't want to knock the development effort, and the web interface is
really nice and the concept is great, just want to give some feedback
now, and if you point me at the right place (and you want it done - I
can add the ORM code).
Finally, I made the comment on Paul Freemantle's blog, the big benefit
of ebRIM is resource associations, owner->dataset, service->dataset
etc. How is this being envisaged for the registry?
Great effort, and thank you - registries are a very hot topic in the
geospatial world.
thanks,
Norman
_______________________________________________
Registry-dev mailing list
[email protected]
http://wso2.org/cgi-bin/mailman/listinfo/registry-dev
--
Paul Fremantle
Co-Founder and VP of Technical Sales, WSO2
OASIS WS-RX TC Co-chair
Office: +1 646 290 8050
Cell: +44 798 447 4618
blog: http://pzf.fremantle.org
[EMAIL PROTECTED]
"Oxygenating the Web Service Platform", www.wso2.com
_______________________________________________
Registry-dev mailing list
[email protected]
http://wso2.org/cgi-bin/mailman/listinfo/registry-dev
