portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gonzalo Aguilar Delgado <gagui...@aguilardelgado.com>
Subject Re: Questions about the page manager
Date Fri, 25 Jun 2010 06:48:36 GMT
Mmmm!

I not counted on that! I suppose that jackrabbit caching will not offer
a complete solution after all as it can return different instances each
time.

I really don't know if I will be able to handle all this amount of
changes int that short time but I will try. If something looks incorrect
or not good enough let's amend it after... Let's consider this a
"incubation" project.

Thank you again Randy.


El jue, 24-06-2010 a las 14:58 -0600, Randy Watler escribió:
> 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
> 


---------------------------------------------------------------------
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