portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Randy Watler <wat...@wispertel.net>
Subject Re: Jackrabbit page manager [Progress]
Date Fri, 09 Jul 2010 21:35:25 GMT
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-unsubscribe@portals.apache.org
>> For additional commands, e-mail: jetspeed-dev-help@portals.apache.org
>>
>>     
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
> For additional commands, e-mail: jetspeed-dev-help@portals.apache.org
>
>
>   


---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-dev-help@portals.apache.org


Mime
View raw message