Gonzalo,
Sounds like you are making some good progress.
I am not sure what you are referring to when you say that structure and
usage are simpler... changing the public APIs to the page manager
component should not be done unless absolutely necessary. If you are
making changes, those need to be propagated to the other existing
implementations.
Both the Castor and OJB implementations implement lazy loading in their
own way, so it is good that you followed that pattern with the JCR version.
The test case coverage is incomplete to say the least. The issues that I
raised here are characteristics of the existing implementations. These
are primarily implemented by caching withing Jetspeed, (ehcache). You
are using jackrabbit caching per JCR session IIRC. This may or may not
behave as other code in Jetspeed expects.
There are already techniques and tools in place to migrate data from one
PM implementation to another, so you should not have to write any code
or scripts to make that happen.
Finally, remember that we can not obsolete the existing PM
implementations. We will have to add your Jackrabbit implementation as a
3rd PM option. This means extending the existing build and spring
configuration.
Hope this helps clear things up. Good work!
Randy
Gonzalo Aguilar Delgado wrote:
Hi there,
New page manager based on jackrabbit it's passing testcases proposed in
the other two implementations. Tomorrow I will make it pass
TestXXXPageManager:testCreatePage() and I hope some other simpler
ones...
I also will measure times between Castor implementation and jackrabbit
and will do some Threading tests if I have time. It uses cache by
default.
Structure seems to be simpler and usage is also simpler. Also some
"extra" features can be implemented easier too.
We don't have to care about loading childs and parents it's
automagically handled by jackrabbit. Also lazy initialization will
decrease loading times, I hope.
Extending is also simpler because OM engine.
I will try to write a loading script to load castor files into the
repository.
I'm worried about two issues that Randy told me about:
"The same Java instance must be returned for the same persistent
object" -> I will need a test case or just point me to the piece of code
that requires it to see where implement the wrapper.
"the object model needs to be thread safe" -> Not an expert on this but
will try to run tests in multithreaded environment. How do you achieve
this on the other managers. Didn't see anything special.
If everything goes right it will provide at least what I was looking
for:
Separate management of cms objects.
Stability: As everything is handled inside jackrabbit. When
someone fix a bug in jackrabbit, jetspeed will take advantage of
it.
Ease of use: Lot of tools are provided by jackrabbit project,
let's use them.
Speed: It runs in a different thread and custom optimizations.
If I manage to work around constraints Randy told me I'm sure it
will be faster.
Better concurrency.
Easy to extend: We will be able to extend more easily.
I hope it works.
El lun, 28-06-2010 a las 12:47 +0200, Gonzalo Aguilar Delgado escribió:
Hi there!
I've been creating node types for the jackrabbit content handler. I'm
writing QA tests and doing some other tests.
I've created nodes for this types of contents:
1.- Folder
2.- File
3.- Fragment
4.- Content - (Image files, binary content, etc)
What other content nodes should exists? I mean, Are there other kind of
nodes?
Maybe it can be useful to add Space object in a way that inherits from
folder so this way we can add custom properties. Maybe it should be one
node for the toolbox so we can add and remove the toolbox from the page.
Is there a tree to see what's the current structure of the CMS part of
the portal? This way I can check what to include and how to do it.
Don't know. I'm not an expert on this...
What do you suggest? After, we can improve it even more.
I think it will be really easy do management this way because
persistence of the nodes will be completely transparent.
____________________________________
Gonzalo Aguilar Delgado
Consultor CRM - Ingeniero en
Informática
M. +34 607814276
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscr...@portals.apache.org
For additional commands, e-mail: jetspeed-dev-h...@portals.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscr...@portals.apache.org
For additional commands, e-mail: jetspeed-dev-h...@portals.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscr...@portals.apache.org
For additional commands, e-mail: jetspeed-dev-h...@portals.apache.org
