Mailing-List: contact jetspeed-dev-help@portals.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Jetspeed Developers List" <jetspeed-dev@portals.apache.org>
Received-SPF: pass (nike.apache.org: local policy)
Subject: Re: Jackrabbit page manager [Progress]
From: Gonzalo Aguilar Delgado <gaguilar@aguilardelgado.com>
To: Jetspeed Developers List <jetspeed-dev@portals.apache.org>
In-Reply-To: <4C37961D.4060502@wispertel.net>
References: <1277722064.29400.131.camel@azul1>
	 <1278708653.11720.48.camel@azul1>  <4C37961D.4060502@wispertel.net>
Content-Type: text/plain; charset="UTF-8"
Date: Tue, 13 Jul 2010 20:15:52 +0200
Message-ID: <1279044952.12076.46.camel@azul1>
Mime-Version: 1.0
Content-Transfer-Encoding: 8bit

Hi Randy, 

Let me go inline as there are much things here...


> Gonzalo,
> 
> Sounds like you are making some good progress.

Yes. I'm pretty excited about this implementation. It could be useful or
maybe not... You all will decide... But it gives me a try with
jackrabbit and Jetspeed. I really needed this to see the insights in a
piece of code that nobody is touching, updating or working with...

Jetspeed is a very complex piece of work.


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

First of all. I will not touch anything of the public API. 

But I found that structure is too deep to be understandable easily. For
example, the page interface is structured as follows:

Page
  -> BaseConcretePageElement
	-> BasePageElement
              -> BaseFragmentsElement
			-> Document
				-> Node
					-> BaseElement
						-> SecuredResource

But folder extends from Node and SecuredResource...

For me this makes a nosense for my because folder must implement also
setSkin,  getFragmentDefinitions, and others that should be already
implemented in any of the superclasses in this case maybe
BaseFragmentsElement or similar.

If you take a look to the class definitions you can see they are even
more complex. As interfaces does not corresponds to classes and there
are lots of intermediate classes that are not really shared anywhere. I
got lost quickly on first sight... Surely it's my fault but seems
complex for me.

If you have an schema it will help me a lot. :D

I want to try share as much as possible in pages, folders and others.
And create a narrow structure with not much classes. For me it should
not be much differences between a page and a folder. They have a
theme/skin, some properties for security and fragments.

Don't worry I will not touch API at all but will try to make things
easier. I hope I can...


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

Yes... That also comes from jackrabbit. It surprised me because I come
from hibernate and was great to see that this feature also is present in
jackrabbit.


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

Yes. I realize that's not complete. I will try to add my own tests. But
as I said I really don't know how jetspeed expects them... :D So I need
to try. It will be no easy, for sure...


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

I will ask when ready. Tnx.

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

Of course not! It's alpha project. Let's see if it works. But anyway
both other implementations are needed. For me it would be nice to
deprecate Castor implementation somewhere in the future because it looks
obsolete for me. There are other options to do the same. I also prefer
pojo objects instead xml objects. But this is just my preference.


> Hope this helps clear things up. Good work!

Yes. Thanks!

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


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