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: Questions about the page manager
Date Thu, 24 Jun 2010 20:58:01 GMT
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: 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
>>
>>     
>
>
> ---------------------------------------------------------------------
> 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