You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jetspeed-dev@portals.apache.org by Gonzalo Aguilar Delgado <ga...@aguilardelgado.com> on 2010/06/28 12:47:44 UTC
Jackrabbit page manager [Progress]
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
Re: Jackrabbit page manager [Progress]
Posted by Gonzalo Aguilar Delgado <ga...@aguilardelgado.com>.
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
Re: Jackrabbit page manager [Progress]
Posted by Randy Watler <wa...@wispertel.net>.
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
Re: Jackrabbit page manager [Progress]
Posted by Gonzalo Aguilar Delgado <ga...@aguilardelgado.com>.
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