jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sorel <johann.so...@geomatys.fr>
Subject Re: [jr3] Wrapped intelligent objects
Date Thu, 18 Feb 2010 08:45:24 GMT
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 
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 :

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

View raw message