Justin Edelson wrote:
Did you try Object Content Mapping (OCM) with JCR (eg. Jackrabbit OCM)?
In the end, the objects you want to store have fields that boil down
to the basic properties (and if sth doesn't fit well, there is always
string, which can be searched). Real object databases would be close
to what you have in mind, but they always have the advantage that the
data and fields/properties are not very visible, ie. there are no
generic, standardized ways to look at the data, independent from the
specific programming language they are designed for.
We only use jackrabbit JCR commun module, and we don't intent to use any
more
module or we will lose all our cache structure (duplicate would be more
extact).
The problem is not the storage anyway.
I'm not sure I understand what you're saying here about your cache
structure, but I agree with Alex - the "intelligent object" problem you
describe above seems to solved by OCM.
let's take an exemple :
Imagine Liferay for exemple, 2 companies manage somehow to expose
repositories
in liferay by adding each one a plugin. thoses repositories are now
visible by any portlet in liferay. Each
repository have geographic datas clearly defined by a well knowned Node
type.
Now you add a mapping jsf portlet made by a third company that can
access thoses repository and can render
any object that match this node type. problem is, the attributs are not
enough to render a map, he needs acces to
the hidden object, objects that follow another specification.
But unfortunatly he can't since not method on the JCR node interface can
give him this object.
And why do you think you can't do this with OCM?
The mapping portlet would just need to use the ObjectContentManager to
get an instance of your custom class. The only difference is that
instead of the Node having a "hidden" instance of a custom class, the
portlet just gets an instance of the custom class. Which is actually
simpler
The third application only knows the JSR-275 (JCR). it knows how
to speak to them whatever implementation they are (jackrabbit,
exoplatform ...)
So he can't acces the ObjectContentManager which is specific to jackrabbit.
Keep in mind that the only thing you can rely on from outside are the
specification
interfaces. If you force a application to rely directly on jackrabbit to
do it's work then
you misunderstand the purpose of the JCR specification.
Using JCR is a bit like being in front of a no entrance bunker,
informations are exposed through a small perfectly formatted window.
The bunker has a big sign writen : "hospital", ho! great I'm a doctor, I
can talk my own language (specification) with them (100times more
efficient) but how do I get in ? there is no entrance.
I believe there is a need for this door otherwise JCR will be
incompatible with any other specification.
I'm not sure what other specifications you're referring to here. Can you
elaborate?
OGC = Open Geospatial Consortium. http://www.opengeospatial.org/
I have plenty, ISO 19107 (geometries), OGC GML (geographic markup language),
ISO 19105 referencing. ISO 19109 Feature ... and plenty others.
They are more then just specification, they are standards.
They have been translated in java interface in the OGC GeoAPI standard :
http://geoapi.sourceforge.net/
So here is my question : how do you get acces to object following the
GeoAPI standard
through the JCR specification (not jackrabbit) ? I don't see any.
johann sorel
