Gonzalo,
No doubt it is tempting to let Jackrabbit do all the caching. Beware
though that this approach may cause problems within Jetspeed which
requires that the same Java instance is returned for the same persistent
object. At the moment, this holds true across multiple requests and
users! In case you are scratching your head, yes, the object model needs
to be thread safe and operate as if there is no transaction isolation.
Changing this in Jetspeed represents a large amount of work which is why
it has not been done already. Consider yourself forewarned!
Randy
Gonzalo Aguilar Delgado wrote:
Hi Randy,
Those are good news. This way I can flatten a little bit the model and
create nodes only for what's really used. Also the repository will be
able to check against structure to ensure that everything correct.
About caching. I think it will be best let jackrabbit do all the caching
because it support several models for this. Even better, if something
goes not fast enough I surely can write a new strategy for this.
Ok. Let's do one thing. Let me analyze node types I will need. I will
create a base implementation that works. And after that comments will be
welcome.
I really think that this can help a lot for future developments.
Thank you very much for your accessibility Randy.
El jue, 24-06-2010 a las 13:44 -0600, Randy Watler escribió:
Gonzalo,
The implementation class hierarchy is up to you since it is hidden...
you just need to implement the same interfaces.
Caching is an important consideration with all of this. If you do not
model things with collections, you will be forced to traverse each
collection when it is accessed instead. The trivial implementation that
hits the JCR repo, RDBMS, or file system per request may not perform
adequately. This is why the object models are self referential instead
of path based.
There are also some artifacts in the DBPM that were required to map it
onto structures required by OJB. Obviously, those may not be necessary
in your implementation.
Randy
Gonzalo Aguilar Delgado wrote:
Hi Randy,
I'm working on page hierarchy. I see that there are much
AbstractBaseXXXX classes mixed with some Impl classes.
Each of them implements one kind of Interface. Ex:
public abstract class AbstractBaseFragmentsElement extends DocumentImpl
implements BaseFragmentsElement
Is all this hierarchy really needed? I'm thinking about possibility of
flatten a little bit the structure and simplify things.
Also I think that with jackrabbit is no longer necessary to keep
reference to child objects inside classes because path define childrens.
So no need for:
private BaseFragmentElement root = null;
private FragmentElementImpl rootFragmentElementImpl = null;
Do you think that all this is really necessary?
Thank you.
____________________________________
Gonzalo Aguilar Delgado
Consultor CRM - Ingeniero en
Informática
M. +34 607814276
El jue, 24-06-2010 a las 06:16 -0600, Randy Watler escribió:
Hi Gonzolo,
I am the PageManager "expert" if there is such a thing. See the comments
inline below.
HTH,
Randy
Gonzalo Aguilar Delgado wrote:
Hi David and Woonsan,
I've done my way to implementing the jackrabbit page manager. This will
provide:
Unified page managing.
Services as WebDAV for page manager.
Version control.
Repository connections (This will open doors to multisite
manager).
Bring unified metadata handling via jackrabbit metadata utils.
Separate page manager logic from application.
etc.
If you've managed all of that, you have certainly been busy!
But I have some questions I don't really know if they are related to the
work I'm doing right now.
1.- When doing tests I see that Castor page manager tries to transform
source testdata when copying to target directory. Why this is done?
Because it results into the same file...
It is done since the test modifies the files during execution and thus
does not operate directly on the source controlled originals. Thsi is
obviously not done with the DBPM.
2.- Bean manager... I'm getting crazy about how pageManager is plugged
into the Jetspeed portal. Maybe because I'm also not a Spring expert.
[ File assembly/page-manager.xml ]
I see two BeanReferenceFactoryBean:
xmlPageManager and dbPageManager
That's right... The portalSite Bean has one argument to the index 0 arg
of the constructor:
<constructor-arg index="0">
<ref bean="org.apache.jetspeed.page.PageManager" />
</constructor-arg>
How does it knows to select if xmlPageManager or dbPageManager must be
plugged in. Does it has something to do with meta key?
Jetspeed has extended the normal use of Spring to include dynamic
binding. This is indeed accomplished via the categories/meta support.
There is a properties file, I think it is names spring-keys.properties,
or something like that, it selects which bean meta keys are used at
runtime. Beans that do not match are ignored.
I'm really lost. I debugged jetspeed and saw that for me
xmlPageManager(Castor one) is plugged in... But why? I don't find any
reference to it?
I have to say that got a little bit lost with the bean names being fully
qualified ones. org.apache.jetspeed.portalsite.PortalSite pointed to an
Interface that got me confused until I realized that was only a name and
that real bean (impl one) got plugged instead...
Thank you!
____________________________________
Gonzalo Aguilar Delgado
Consultor CRM - Ingeniero en
Informática
M. +34 607814276
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
