GroupBasedProfileManager
After looking at the AuthenticationProfileManager code I decided to review the GroupBasedProfileManager. While I'm happy to see the read/write lock stuff gone it seems that getGlobalBaseDatas and getGlobalDatas could have a race condition if two threads run at the same time. Both threads could very well create the CopletBaseData or worse getGlobalBaseDatas might clear copletDatas.object right after the other thread has set it in getGlobalDatas.
Re: [RT] The Real Component Simplification
Daniel Fagerstrom wrote: Decomponentization could start right away. Do you have any concrete examples of components that shouldn't be components? The XMLSerializer/XMLDeserializer combo is one of the best examples, I think. These shouldn't be components. If noone objects I'll do the changes for 2.2 - we already discussed this years ago :) Carsten -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: GroupBasedProfileManager
Ralph Goers wrote: After looking at the AuthenticationProfileManager code I decided to review the GroupBasedProfileManager. While I'm happy to see the read/write lock stuff gone it seems that getGlobalBaseDatas and getGlobalDatas could have a race condition if two threads run at the same time. Both threads could very well create the CopletBaseData or worse getGlobalBaseDatas might clear copletDatas.object right after the other thread has set it in getGlobalDatas. Argh, you're right - now, the methods are synchronized...but obviously that doesn't help. I must have written this code directly after some party I guess. I'll have a look at it today. Carsten -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: GroupBasedProfileManager
Carsten Ziegeler schrieb: Ralph Goers wrote: After looking at the AuthenticationProfileManager code I decided to review the GroupBasedProfileManager. While I'm happy to see the read/write lock stuff gone it seems that getGlobalBaseDatas and getGlobalDatas could have a race condition if two threads run at the same time. Both threads could very well create the CopletBaseData or worse getGlobalBaseDatas might clear copletDatas.object right after the other thread has set it in getGlobalDatas. Argh, you're right - now, the methods are synchronized...but obviously that doesn't help. I must have written this code directly after some party I guess. I'll have a look at it today. Ok, perhaps the code isn't that bad...now, both methods (getGlobalBaseDatas and getGlobalDatas) are synchronized, so only one thread can enter them and therefore only one thread can change the corresponding objects. At the end of the method, the map is returned and this return value is then used for the current user profile. So, if now another thread is entering the getGlobalBaseDatas method and overwriting the copletBaseDatas.objects value, the first user is not affected as he is working on his copy. At least this is how I think it should work. WDYT? Carsten -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: [RT] The Real Component Simplification
Carsten Ziegeler wrote: Daniel Fagerstrom wrote: Decomponentization could start right away. Do you have any concrete examples of components that shouldn't be components? The XMLSerializer/XMLDeserializer combo is one of the best examples, I think. These shouldn't be components. If noone objects I'll do the changes for 2.2 - we already discussed this years ago :) Carsten +1 /Daniel
Re: XTech 2006 Amsterdam, May 16-19th
Stefano Mazzocchi wrote: Arje Cahn wrote: FYI, I'm on the technical review board of that conference. Will you attend too? Don't know, probably not, but I'll have to be in Sweden the week after that to given a keynote speech, so I might be able to stop by ;-) What conference are you giving your keynote speach in? /Daniel
Re: [RT] The Real Component Simplification
Carsten Ziegeler wrote: Daniel Fagerstrom wrote: Decomponentization could start right away. Do you have any concrete examples of components that shouldn't be components? The XMLSerializer/XMLDeserializer combo is one of the best examples, I think. These shouldn't be components. Definitely! If noone objects I'll do the changes for 2.2 - we already discussed this years ago :) +1 Sylvain -- Sylvain WallezAnyware Technologies http://bluxte.net http://www.anyware-tech.com Apache Software Foundation Member Research Technology Director
[M10N] Time to finish
It is time to finish the Mavenization. Jorg, others, what is left to do? We need a todo list so that we all can help finish it. Jorg, you did some experimentation with flattening the structure, what was the result? IMO, even if component management, blocks and next generation stuff are interesting, finish M10N should be our number one priority right now. /Daniel
RE: [M10N] Time to finish
--- Daniel Fagerstrom [EMAIL PROTECTED] schrieb: It is time to finish the Mavenization. Jorg, others, what is left to do? We need a todo list so that we all can help finish it. Jorg, you did some experimentation with flattening the structure, what was the result? IMO, even if component management, blocks and next generation stuff are interesting, finish M10N should be our number one priority right now. Over Christmas I was working on the deployer. I hope that I will be able to commit it next week. I will also start to write a tutorial (hopefully Jorg can help me here a bit) describing the Cocoon 2.2 development process based on M2 so that we can discuss it without even having the complete implementation. I hope we can identify the rough edges this way and make it easy for non-M2-specialists to join the discussion. -- Reinhard ___ Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
[CForms] Move to postion
Hi all,
I would like to implement a row action move-to-position.
We have already move-up and move-down, but I would like to move the row
to an user specific position. You have an input box (new-position) for
each row where you define the new position for the row.
I defined a new action MoveToPositionDefinition{} in the
RowActionDefinition based on MoveUpDefinition{} and my corresponding
form stuff.
Now my question is the following:
What is the best way to get the value of the new-position box in the
definition?
salu2
--
thorsten
Together we stand, divided we fall!
Hey you (Pink Floyd)
Re: [CForms] Move to postion
Thorsten Scherler wrote:
Hi all,
I would like to implement a row action move-to-position.
We have already move-up and move-down, but I would like to move the row
to an user specific position. You have an input box (new-position) for
each row where you define the new position for the row.
From a usability point of view, this looks a bit weird...
And as we speak, I'm working on drag'n drop reordering of repeater rows.
Using DnD in tables is quirky (I understand now why Dojo and
Scriptaculous demos are all list-based) but I'm progressing.
I defined a new action MoveToPositionDefinition{} in the
RowActionDefinition based on MoveUpDefinition{} and my corresponding
form stuff.
Now my question is the following:
What is the best way to get the value of the new-position box in the
definition?
I'm more and more thinking that a repeater needs to have child widgets
that are not in rows, i.e. a repeater is a container for rows (which are
themselves containers) _and_ other widgets, such as repeater actions.
Also, I think the selection must be a feature of the repeater, rather
than through a boolean field that has to be manually added as of today.
That would allow to define at the repeater level if selection is
allowed, and if it single or multiple. Also that would allow to have
repeater.getSelectedRows().
WDYT?
Sylvain
--
Sylvain WallezAnyware Technologies
http://bluxte.net http://www.anyware-tech.com
Apache Software Foundation Member Research Technology Director
I'm lost...could we have more README files?
Hi devs, I've been trying to keep up with what's happening in the trunk, without being able to invest continuous time here currently, and I must admit that I'm lost in several areas. IMHO it's currently hard to find how to try out the following features/run modes/stuff: -Build with Maven -Blocks mode -JMX features -Development vs. deployment mode (IIRC Carsten has implemented something cool with properties) -OSGI mode -I might have forgotten other exciting stuff Would it be possible for people working in these areas to create short README files in the trunk, and keep them up to date when something happens in that area? There's already README.osgi, we could have README.maven, README.jmx, README.blockmode, etc.. My goal is to allow any of us to experiment with these new features even if they haven't followed them closely, by finding the necessary information, links, status etc. in one place. So, I'd be thankful if people who work in these areas could keep us up to date in this way, so that we can share the excitment about these new features. I know this ultimately belongs to some docs, but as these things are still evolving it's much easier to keep a single file up to date per feature/mode. If docs are here already, just put an link to them in the README file. Thanks for listening ;-) -Bertrand smime.p7s Description: S/MIME cryptographic signature
Re: [M10N] Time to finish
Reinhard Poetz wrote: --- Daniel Fagerstrom [EMAIL PROTECTED] schrieb: It is time to finish the Mavenization. Jorg, others, what is left to do? We need a todo list so that we all can help finish it. Jorg, you did some experimentation with flattening the structure, what was the result? IMO, even if component management, blocks and next generation stuff are interesting, finish M10N should be our number one priority right now. Over Christmas I was working on the deployer. I hope that I will be able to commit it next week. Sounds great! I will also start to write a tutorial (hopefully Jorg can help me here a bit) describing the Cocoon 2.2 development process based on M2 so that we can discuss it without even having the complete implementation. I hope we can identify the rough edges this way and make it easy for non-M2-specialists to join the discussion. Sounds great as well. But I'm more impatient ;) A deployer is AFAICS a new feature, my question is: what is the minimal amount of work we need to do to replace the current Ant build system with M2? IIRC, all Cocoon with blocks included, where possible to build with M2 a couple of months ago. Now just the core is built from the main POM. What is needed for building everything and create a working webapp? IMO, we should focus on switching to M2, ASAP. All new features can wait, the important thing is to get something that replaces the current build system. It is time that we as a community takes responsibility for the M2 build. If there are some rough edges, or that the system sometimes becomes unstable, that is something that we have to deal with, we shouldn't wait for you and Jorg to finish and polish everything. A lot of people in our community have started to learn about using M2, and Jason and Bret seemed commited to help us if we run into problems when we talked to them during ApacheCon. We should, IMO, just switch ASAP and solve the problems as they come. So, what would a minimal plan for switching be? /Daniel
Re: [CForms] Move to postion
El jue, 05-01-2006 a las 11:26 +0100, Sylvain Wallez escribió:
Thorsten Scherler wrote:
Hi all,
I would like to implement a row action move-to-position.
We have already move-up and move-down, but I would like to move the row
to an user specific position. You have an input box (new-position) for
each row where you define the new position for the row.
From a usability point of view, this looks a bit weird...
And as we speak, I'm working on drag'n drop reordering of repeater rows.
Using DnD in tables is quirky (I understand now why Dojo and
Scriptaculous demos are all list-based) but I'm progressing.
:) jeje very nice. :)
Actually this would solve my usecase perfectly. My form is a nested
repeater. The user want to move the repeater rows to any given position
and not by clicking 20 times up. ;-)
When do you think it is ready to test. ;-)
I defined a new action MoveToPositionDefinition{} in the
RowActionDefinition based on MoveUpDefinition{} and my corresponding
form stuff.
Now my question is the following:
What is the best way to get the value of the new-position box in the
definition?
I'm more and more thinking that a repeater needs to have child widgets
that are not in rows,
Yes, I agree. In my use case I ended up to add tmp variable to the form
where it would have been easier to use child widgets directly.
i.e. a repeater is a container for rows (which are
themselves containers) _and_ other widgets, such as repeater actions.
+1
Also, I think the selection must be a feature of the repeater, rather
than through a boolean field that has to be manually added as of today.
+1 makes the template lot cleaner
That would allow to define at the repeater level if selection is
allowed, and if it single or multiple. Also that would allow to have
repeater.getSelectedRows().
WDYT?
Yeah, very nice.
Thanks Sylvain
salu2
--
thorsten
Together we stand, divided we fall!
Hey you (Pink Floyd)
Re: [M10N] Time to finish
Le 5 janv. 06, à 11:40, Daniel Fagerstrom a écrit : ...IIRC, all Cocoon with blocks included, where possible to build with M2 a couple of months ago. Now just the core is built from the main POM. What is needed for building everything and create a working webapp?.. I haven't been able to test the Maven stuff lately, but I'd like to mention that the HtmlUnit tests will need to run under Maven once they're ported to 2.2. Currently in 2.1x you need to start an instance of Cocoon with cocoon.sh, and run another JVM with build.sh htmlunit-tests. I've seen some code (from Daniel IIRC) fly by, which uses a more integrated testing method, starting the servlet under test in the same JVM, but I don't know what the preferred way is with Maven. Of course, the 2.1.x way of running these tests is not suitable to automated continuous integration. Dunno how much impact this has on the Maven stuff, just wanted to make sure this is not forgotten. And if someone has pointers on how to do this the right way, I hope to find some time to port these tests to 2.2. at some point. -Bertrand smime.p7s Description: S/MIME cryptographic signature
Re: I'm lost...could we have more README files?
Bertrand Delacretaz wrote: Hi devs, I've been trying to keep up with what's happening in the trunk, without being able to invest continuous time here currently, and I must admit that I'm lost in several areas. IMHO it's currently hard to find how to try out the following features/run modes/stuff: -Build with Maven -Blocks mode -JMX features -Development vs. deployment mode (IIRC Carsten has implemented something cool with properties) -OSGI mode -I might have forgotten other exciting stuff Would it be possible for people working in these areas to create short README files in the trunk, and keep them up to date when something happens in that area? There's already README.osgi, And it actually worked when I tested it during ApacheCon ;) we could have README.maven, README.jmx, README.blockmode, etc.. The block mode is currently in a state of flux. You could use Cocoon in blocks mode a month ago by running ./cocoon.sh blocks. That worked by making the root Processor pluggable in the CocoonServlet and using the BlocksManager instead of Cocoon. To make that possible, I had to have a rather complicated initalization sequence for the blocks. After the NG discussions I decided to simplify the architecture by refactoring the block architecture so that the BlocksManager becomes a top level servlet instead. And so that the ServiceManager and Avalon context creation happen locally at the block level instead of globaly. This is ongoing work and currently the blockmode is only usable from the test cases. But I hope to finish the refactoring soon and then I will write a README.blocksmode. /Daniel
Re: I'm lost...could we have more README files?
Le 5 janv. 06, à 12:18, Daniel Fagerstrom a écrit : ...This is ongoing work and currently the blockmode is only usable from the test cases. But I hope to finish the refactoring soon and then I will write a README.blocksmode... Thanks - I have added your explanation to README.blocksmode already, I hope you don't mind. In this way people can find out there about the current state. -Bertrand smime.p7s Description: S/MIME cryptographic signature
Re: [M10N] Time to finish
Daniel Fagerstrom wrote: It is time to finish the Mavenization. Jorg, others, what is left to do? We need a todo list so that we all can help finish it. I've lined out the (IMO) outstanding stuff here [1]. As said later in the thread, it depends on how far you want to take this. m2 has been able to compile and (somewhat) package core for months now. My hesitation in pushing this forward mainly lies in the fact that it's a change that affects *everybody*, and the less you know about maven the more you'll perceive yourself being affected. I thought that waiting a bit longer would give ppl more the chance to get up to speed with m2 in general. Jorg, you did some experimentation with flattening the structure, what was the result? It makes it much easier to manage, maintain and oversee the maven build process. The experiment was very positive, you can still check out the flat layout in the whiteboard and play around with it [2]. The benefits towards componentisation are well known and accepted by everyone. In short, i don't see any reason to keep the old structure. If someone gives me the green light (again) and people are not afraid of a bit of a bumpy ride in trunk for a while then I can start flattening trunk *today* (as in __now__). Core, tests, mocks and a few of the more used blocks are obvious candidates. We can decide about the blocks that are externalized from branch later. Ofcourse I'll document the moving a block to the flat structure process as well as i go along. Regards Jorg [1] http://thread.gmane.org/gmane.text.xml.cocoon.devel/59180 [2] http://thread.gmane.org/gmane.text.xml.cocoon.devel/57694
Re: [M10N] Time to finish
Jorg Heymans wrote It makes it much easier to manage, maintain and oversee the maven build process. The experiment was very positive, you can still check out the flat layout in the whiteboard and play around with it [2]. The benefits towards componentisation are well known and accepted by everyone. In short, i don't see any reason to keep the old structure. If someone gives me the green light (again) and people are not afraid of a bit of a bumpy ride in trunk for a while then I can start flattening trunk *today* (as in __now__). Core, tests, mocks and a few of the more used blocks are obvious candidates. We can decide about the blocks that are externalized from branch later. Ofcourse I'll document the moving a block to the flat structure process as well as i go along. + (= green) Carsten
Re: [M10N] Time to finish
Le 5 janv. 06, à 13:58, Jorg Heymans a écrit : ...If someone gives me the green light (again) and people are not afraid of a bit of a bumpy ride in trunk for a while then I can start flattening trunk *today* (as in __now__)... I think this deserves a [VOTE], which is the best green light you can get. I'm +1 of course...but would like a README.maven ;-) -Bertrand smime.p7s Description: S/MIME cryptographic signature
Re: [M10N] Time to finish
Daniel Fagerstrom wrote: Sounds great as well. But I'm more impatient ;) A deployer is AFAICS a new feature, my question is: what is the minimal amount of work we need to do to replace the current Ant build system with M2? IIRC, all Cocoon with blocks included, where possible to build with M2 a couple of months ago. Now just the core is built from the main POM. What is needed for building everything and create a working webapp? that's because i've commented out the other modules in the root pom. I fixed the webapp yesterday so that it runs again, i'll commit this now. All you have to do from /webapp is war:inplace and point jetty to the root of the webapp. IMO, we should focus on switching to M2, ASAP. All new features can wait, the important thing is to get something that replaces the current build system. +1 It is time that we as a community takes responsibility for the M2 build. +1000 If there are some rough edges, or that the system sometimes becomes unstable, that is something that we have to deal with, we shouldn't wait for you and Jorg to finish and polish everything. A lot of people in our community have started to learn about using M2, and Jason and Bret seemed commited to help us if we run into problems when we talked to them during ApacheCon. We should, IMO, just switch ASAP and solve the problems as they come. So, what would a minimal plan for switching be? IMO just to start flattening the trunk, things will become easier to manage and ppl can more easily participate in the m2 build process. Getting the webapp to run automatic block deployment is not needed for switching IMO, people can initially just copy the stuff manually. Regards, Jorg
Re: [M10N] Time to finish
Bertrand Delacretaz wrote: Le 5 janv. 06, à 11:40, Daniel Fagerstrom a écrit : ...IIRC, all Cocoon with blocks included, where possible to build with M2 a couple of months ago. Now just the core is built from the main POM. What is needed for building everything and create a working webapp?.. I haven't been able to test the Maven stuff lately, but I'd like to mention that the HtmlUnit tests will need to run under Maven once they're ported to 2.2. Currently in 2.1x you need to start an instance of Cocoon with cocoon.sh, and run another JVM with build.sh htmlunit-tests. I've seen some code (from Daniel IIRC) fly by, which uses a more integrated testing method, starting the servlet under test in the same JVM, I have used functional testing at the Processor level for developing virtual sitemap components and blocks (o.a.c.test.SitemapTestCase). Now when I'm refactoring the block architecture to use Servlet instead of Processor I'm using ServletUnit from HttpUnit instead (o.a.c.test.ServletTestCase). Unfortunally ServletUnit sucks for my needs. It is rather inflexible in the setup, the code is complicated for what it does (might be coupled to needs in HttpUnit) and it silently swallow all servlet log messages and internal stack traces. So when things go wrong during development there are signs on what happened :/ IMO we need functional tests on the controller level, especially if we are going to make controllers first class citicens. For ServletUnit we either need to fix it so that it gives decent log messages and stack traces or develop our own. but I don't know what the preferred way is with Maven. Of course, the 2.1.x way of running these tests is not suitable to automated continuous integration. I have found it very practical to test Processor and Servlet in an embeded environment. Something similar is possible for HtmlUnit, it has a hook (which is documented as unstable and for internal use :/ ) so that one can connect it directly to a Processor or Servlet (with appropriate environment setup) in the same VM. Dunno how much impact this has on the Maven stuff, We should start by replacing Ant, new features can be added later. just wanted to make sure this is not forgotten. And if someone has pointers on how to do this the right way, I hope to find some time to port these tests to 2.2. at some point. Great! I don't know the right way, but I certainly have opinions ;) /Daniel
Re: [RT] The Real Component Simplification
Berin Loritsch wrote: Daniel Fagerstrom wrote: Decomponentization could start right away. Do you have any concrete examples of components that shouldn't be components? Pipeline (sure we have two implementations, but that doesn't mean it has to be a component) Five implementations. And I imagine after interface cleanup and for pipeline API, pipeline should stay component. URL interpretation ? Just about anything that is not a Processor, Generator, Transformer, Serializer, or Reader. You forgot Matchers, Selectors, and Actions. Every but small projects have bunch of those. Stores. Swapped very frequently, several implementations, and Cocoon's default is not the fastest gun in the west. Input/output modules. Tons of them. It is very simplistic view of the world to declare that only P/G/T deserve to be components. I'd even go as far as claim that P/G/T are implemented by cocoon users the *least* often compared to other interfaces. Vadim As to Processors, I see the following implementations: 1. current sitemap--complete with its matchers, selectors, actions, and tree processor 2. rails-like router The others are planned extension points that several people have written solutions for.
Re: [RT] The Real Component Simplification
Daniel Fagerstrom wrote: Carsten Ziegeler wrote: Daniel Fagerstrom wrote: Decomponentization could start right away. Do you have any concrete examples of components that shouldn't be components? The XMLSerializer/XMLDeserializer combo is one of the best examples, I think. These shouldn't be components. If noone objects I'll do the changes for 2.2 - we already discussed this years ago :) Carsten +1 +1 Vadim
Re: I'm lost...could we have more README files?
Bertrand Delacretaz wrote: -Build with Maven Good point, I'll create a README.maven in root with enough stuff in it to get people going. Thanks for listening ;-) Thanks for bringing this up! Jorg
Re: [M10N] Time to finish
Bertrand Delacretaz wrote: I haven't been able to test the Maven stuff lately, but I'd like to mention that the HtmlUnit tests will need to run under Maven once they're ported to 2.2. yes i noticed this yesterday when i tried to compile the tests again. Htmlunit has bad poms on ibiblio so we'll have to upload it to cvs.a.o ourselves again. I've seen some code (from Daniel IIRC) fly by, which uses a more integrated testing method, starting the servlet under test in the same JVM, but I don't know what the preferred way is with Maven. Of course, the 2.1.x way of running these tests is not suitable to automated continuous integration. Dunno how much impact this has on the Maven stuff, just wanted to make sure this is not forgotten. And if someone has pointers on how to do this the right way, I hope to find some time to port these tests to 2.2. at some point. It doesn't impact the maven stuff as such. I'ld say we leave those tests out for now and worry about how to run them later. Regards Jorg
Re: [CForms] Move to postion
Thorsten Scherler wrote: El jue, 05-01-2006 a las 11:26 +0100, Sylvain Wallez escribió: Thorsten Scherler wrote: Hi all, I would like to implement a row action move-to-position. We have already move-up and move-down, but I would like to move the row to an user specific position. You have an input box (new-position) for each row where you define the new position for the row. From a usability point of view, this looks a bit weird... And as we speak, I'm working on drag'n drop reordering of repeater rows. Using DnD in tables is quirky (I understand now why Dojo and Scriptaculous demos are all list-based) but I'm progressing. :) jeje very nice. :) Actually this would solve my usecase perfectly. My form is a nested repeater. The user want to move the repeater rows to any given position and not by clicking 20 times up. ;-) When do you think it is ready to test. ;-) This is part of a set of Ajax goodies that have to be finished 1st half of February. But expect them to land incrementally in the repository until then :-) Sylvain -- Sylvain WallezAnyware Technologies http://bluxte.net http://www.anyware-tech.com Apache Software Foundation Member Research Technology Director
Re: [M10N] Time to finish
Jorg Heymans wrote: Daniel Fagerstrom wrote: It is time to finish the Mavenization. Jorg, others, what is left to do? We need a todo list so that we all can help finish it. I've lined out the (IMO) outstanding stuff here [1]. Only the flattening seem to be necessary in a first step, the rest can be done later. As said later in the thread, it depends on how far you want to take this. m2 has been able to compile and (somewhat) package core for months now. My hesitation in pushing this forward mainly lies in the fact that it's a change that affects *everybody*, and the less you know about maven the more you'll perceive yourself being affected. I thought that waiting a bit longer would give ppl more the chance to get up to speed with m2 in general. Sometimes some pushing is necessary. Furthermore it seem like most of the more active developers allready have done their hoework concerning M2, and the rest will feel motivated when we switch ;) Jorg, you did some experimentation with flattening the structure, what was the result? It makes it much easier to manage, maintain and oversee the maven build process. The experiment was very positive, you can still check out the flat layout in the whiteboard and play around with it [2]. The benefits towards componentisation are well known and accepted by everyone. In short, i don't see any reason to keep the old structure. If someone gives me the green light (again) Start a vote rigth away, you have my +1. and people are not afraid of a bit of a bumpy ride in trunk for a while then I can start flattening trunk *today* (as in __now__). Core, tests, mocks and a few of the more used blocks are obvious candidates. We can decide about the blocks that are externalized from branch later. Ofcourse I'll document the moving a block to the flat structure process as well as i go along. Great! /Daniel [1] http://thread.gmane.org/gmane.text.xml.cocoon.devel/59180 [2] http://thread.gmane.org/gmane.text.xml.cocoon.devel/57694
Re: I'm lost...could we have more README files?
Bertrand Delacretaz wrote: Le 5 janv. 06, à 12:18, Daniel Fagerstrom a écrit : ...This is ongoing work and currently the blockmode is only usable from the test cases. But I hope to finish the refactoring soon and then I will write a README.blocksmode... Thanks - I have added your explanation to README.blocksmode already, I hope you don't mind. Rather the opposite :) Thanks. /Daniel
[VOTE] green light for flattening repo structure in trunk
In line of the ongoing M10N process I would like to call a vote for starting the work to flatten the trunk repo structure. Main points to note : It makes it much easier to manage, maintain and oversee the maven build process. The experiment was very positive, you can still check out the flat layout in the whiteboard and play around with it [2]. The benefits towards componentisation are well known and accepted by everyone. In short, i don't see any reason to keep the old structure. and ... it's a change that affects *everybody*, and the less you know about maven the more you'll perceive yourself being affected. I thought that waiting a bit longer would give ppl more the chance to get up to speed with m2 in general. and If someone gives me the green light (again) and people are not afraid of a bit of a bumpy ride in trunk for a while then I can start flattening trunk *today* (as in __now__). Core, tests, mocks and a few of the more used blocks are obvious candidates. We can decide about the blocks that are externalized from branch later. Ofcourse I'll document the moving a block to the flat structure process as well as i go along. Please cast your votes : [ ] flatten the structure and pave the way for a 2.2 release [ ] no because Thanks Jorg
Re: GroupBasedProfileManager
Carsten Ziegeler wrote:
Ok, perhaps the code isn't that bad...now, both methods
(getGlobalBaseDatas and getGlobalDatas) are synchronized, so only one
thread can enter them and therefore only one thread can change the
corresponding objects. At the end of the method, the map is returned and
this return value is then used for the current user profile.
So, if now another thread is entering the getGlobalBaseDatas method and
overwriting the copletBaseDatas.objects value, the first user is not
affected as he is working on his copy. At least this is how I think it
should work. WDYT?
Without looking at the code it sounds like what you have here is
something like this:
getGlobalDatas()
{
data = getGlobalBaseDatas()
doSomethingWith( data )
return data
}
If that is the case (i.e. getGlobalDatas always starts with a copy of
the base datas), then only the getGlobalBaseDatas should be
synchronized. That avoids two different threads synchronizing on the
same monitor because they are accessing different threads. It keeps the
length of holding the monitor at its minimum.
Re: [VOTE] green light for flattening repo structure in trunk
Le 5 janv. 06, à 14:52, Jorg Heymans a écrit : ...Please cast your votes : [ +1] flatten the structure and pave the way for a 2.2 release [ ] no because -Bertrand smime.p7s Description: S/MIME cryptographic signature
Re: [RT] The Real Component Simplification
Vadim Gritsenko wrote: Berin Loritsch wrote: Daniel Fagerstrom wrote: Decomponentization could start right away. Do you have any concrete examples of components that shouldn't be components? Pipeline (sure we have two implementations, but that doesn't mean it has to be a component) Five implementations. And I imagine after interface cleanup and for pipeline API, pipeline should stay component. Not necessarily. Just because there are multiple implementations doesn't necessarily mean it is a component--or should be a component. There are some useful things we can do with a Pipeline such as using the Decorator pattern as opposed to inheritance to add features. Or we could use other OO tricks that just aren't possible or too difficult in a component environment. URL interpretation ? SourceResolver and company Just about anything that is not a Processor, Generator, Transformer, Serializer, or Reader. You forgot Matchers, Selectors, and Actions. Every but small projects have bunch of those. No, I left them out on purpose. Those are elements of the Sitemap--which is an implementation of the Processor. Stores. Swapped very frequently, several implementations, and Cocoon's default is not the fastest gun in the west. Ok. That works. Input/output modules. Tons of them. :/ I think that there are some better ways of dealing with this... But it is an extension point that is useful. It is very simplistic view of the world to declare that only P/G/T deserve to be components. I'd even go as far as claim that P/G/T are implemented by cocoon users the *least* often compared to other interfaces. Well, as da Vinci said, Simplicity is the ultimate sophistication. The key point of the decomponentization process is to reduce the number of extension points to the absolute practical minimum. By being brave about what we leave out, it forces us to think differently about other aspects of the system. I'm thinking way forward here.
Re: [VOTE] green light for flattening repo structure in trunk
Jorg Heymans wrote: Please cast your votes : [X] flatten the structure and pave the way for a 2.2 release [ ] no because And thanks for the hard work! Sylvain -- Sylvain WallezAnyware Technologies http://bluxte.net http://www.anyware-tech.com Apache Software Foundation Member Research Technology Director
Re: [VOTE] green light for flattening repo structure in trunk
...Please cast your votes : [ +1] flatten the structure and pave the way for a 2.2 release [ ] no because Carsten -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: GroupBasedProfileManager
Yes, you are correct. Too late at night. I missed the synchronized(this) in the methods. Out of curiosity (not that it makes any difference), why aren't the methods just synchronized? Carsten Ziegeler wrote: Carsten Ziegeler schrieb: Ralph Goers wrote: After looking at the AuthenticationProfileManager code I decided to review the GroupBasedProfileManager. While I'm happy to see the read/write lock stuff gone it seems that getGlobalBaseDatas and getGlobalDatas could have a race condition if two threads run at the same time. Both threads could very well create the CopletBaseData or worse getGlobalBaseDatas might clear copletDatas.object right after the other thread has set it in getGlobalDatas. Argh, you're right - now, the methods are synchronized...but obviously that doesn't help. I must have written this code directly after some party I guess. I'll have a look at it today. Ok, perhaps the code isn't that bad...now, both methods (getGlobalBaseDatas and getGlobalDatas) are synchronized, so only one thread can enter them and therefore only one thread can change the corresponding objects. At the end of the method, the map is returned and this return value is then used for the current user profile. So, if now another thread is entering the getGlobalBaseDatas method and overwriting the copletBaseDatas.objects value, the first user is not affected as he is working on his copy. At least this is how I think it should work. WDYT? Carsten
RE: [VOTE] green light for flattening repo structure in trunk
[+1 ] flatten the structure and pave the way for a 2.2 release [ ] no because Go for it. Matthew
Re: GroupBasedProfileManager
Ralph Goers wrote: Yes, you are correct. Too late at night. I missed the synchronized(this) in the methods. Out of curiosity (not that it makes any difference), why aren't the methods just synchronized? Hmm, yes, I asked myself the same question, but got no response :( I guess I did this because of inheritance. You can create a subclass overwrite the method and then only synchronize the block inside the method which really needs syncing. -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: [VOTE] green light for flattening repo structure in trunk
Jorg Heymans wrote: In line of the ongoing M10N process I would like to call a vote for starting the work to flatten the trunk repo structure. Please cast your votes : [+1] flatten the structure and pave the way for a 2.2 release Ralph
Re: [VOTE] green light for flattening repo structure in trunk
Please cast your votes : [ +1 ] flatten the structure and pave the way for a 2.2 release [ ] no because /Daniel
RE: [VOTE] green light for flattening repo structure in trunk
...Please cast your votes : [ +1] flatten the structure and pave the way for a 2.2 release [ ] no because Max
Re: [RT] The Real Component Simplification
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thu, 5 Jan 2006, Carsten Ziegeler wrote: Date: Thu, 05 Jan 2006 09:47:01 +0100 From: Carsten Ziegeler [EMAIL PROTECTED] Reply-To: dev@cocoon.apache.org To: dev@cocoon.apache.org Subject: Re: [RT] The Real Component Simplification Daniel Fagerstrom wrote: Decomponentization could start right away. Do you have any concrete examples of components that shouldn't be components? The XMLSerializer/XMLDeserializer combo is one of the best examples, I think. These shouldn't be components. If noone objects I'll do the changes for 2.2 - we already discussed this years ago :) +1 - -- Giacomo Pati Otego AG, Switzerland - http://www.otego.com Orixo, the XML business alliance - http://www.orixo.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDvTNaLNdJvZjjVZARArhBAKDyvZP0PJFPGOoumN3qNszdd+kWtACg4KHO deM/MQyF4esf76tP+m9wT14= =Os2u -END PGP SIGNATURE-
Re: [VOTE] green light for flattening repo structure in trunk
Jorg Heymans wrote: [ +1 ] flatten the structure and pave the way for a 2.2 release Minor point: does it have to be 'cocoon-core', 'cocoon-webapp', 'cocoon-blockname'; could it be 'core', 'webapp', 'block-blockname'? Not sure it will be easy to navigate among all those 'cocoon-foo's :) Vadim
Re: [VOTE] green light for flattening repo structure in trunk
[X] flatten the structure and pave the way for a 2.2 release [ ] no because
Re: [M10N] Time to finish
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thu, 5 Jan 2006, Jorg Heymans wrote: It makes it much easier to manage, maintain and oversee the maven build process. The experiment was very positive, you can still check out the flat layout in the whiteboard and play around with it [2]. The benefits towards componentisation are well known and accepted by everyone. In short, i don't see any reason to keep the old structure. If someone gives me the green light (again) and people are not afraid of a bit of a bumpy ride in trunk for a while then I can start flattening trunk *today* (as in __now__). Core, tests, mocks and a few of the more used blocks are obvious candidates. We can decide about the blocks that are externalized from branch later. Ofcourse I'll document the moving a block to the flat structure process as well as i go along. +1 - -- Giacomo Pati Otego AG, Switzerland - http://www.otego.com Orixo, the XML business alliance - http://www.orixo.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDvTRoLNdJvZjjVZARAjFNAKC5K68pbObPWjf8JrCBNCxYKBvbogCeKlAZ dKIdGMURgDbXSkVJO0RWUIM= =0cXb -END PGP SIGNATURE-
Re: [RT] The Real Component Simplification
Berin Loritsch wrote: Vadim Gritsenko wrote: Berin Loritsch wrote: Pipeline (sure we have two implementations, but that doesn't mean it has to be a component) Five implementations. And I imagine after interface cleanup and for pipeline API, pipeline should stay component. Not necessarily. Just because there are multiple implementations doesn't necessarily mean it is a component--or should be a component. There are some useful things we can do with a Pipeline such as using the Decorator pattern as opposed to inheritance to add features. Or we could use other OO tricks that just aren't possible or too difficult in a component environment. May be URL interpretation ? SourceResolver and company It proved to be very valuable extension point Just about anything that is not a Processor, Generator, Transformer, Serializer, or Reader. You forgot Matchers, Selectors, and Actions. Every but small projects have bunch of those. No, I left them out on purpose. Those are elements of the Sitemap--which is an implementation of the Processor. Stores. Swapped very frequently, several implementations, and Cocoon's default is not the fastest gun in the west. Ok. That works. Input/output modules. Tons of them. :/ I think that there are some better ways of dealing with this... But it is an extension point that is useful. Unified object model and expression language could replace many of those. It is very simplistic view of the world to declare that only P/G/T deserve to be components. I'd even go as far as claim that P/G/T are implemented by cocoon users the *least* often compared to other interfaces. Well, as da Vinci said, Simplicity is the ultimate sophistication. The key point of the decomponentization process is to reduce the number of extension points to the absolute practical minimum. By being brave about what we leave out, it forces us to think differently about other aspects of the system. I'm thinking way forward here. Just don't throw out baby in the heat of fight for simplification :) Vadim
Re: [VOTE] green light for flattening repo structure in trunk
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 [X] flatten the structure and pave the way for a 2.2 release [ ] no because - -- Giacomo Pati Otego AG, Switzerland - http://www.otego.com Orixo, the XML business alliance - http://www.orixo.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDvTSpLNdJvZjjVZARAn9FAJ46FDN/o4Ejjrh3sUw55+FLHNBpRwCeMcsd X0rr5rAFELMKU7JlSaeW/0s= =x6m1 -END PGP SIGNATURE-
Re: [VOTE] green light for flattening repo structure in trunk
On 1/5/06, Jorg Heymans [EMAIL PROTECTED] wrote: [+1 ] flatten the structure and pave the way for a 2.2 release [ ] no because And thanks for taking care of that! -- Gianugo Rabellino Pro-netics s.r.l. - http://www.pro-netics.com Orixo, the XML business alliance: http://www.orixo.com (blogging at http://www.rabellino.it/blog/)
Re: [VOTE] green light for flattening repo structure in trunk
Vadim Gritsenko skrev: ... Minor point: does it have to be 'cocoon-core', 'cocoon-webapp', 'cocoon-blockname'; could it be 'core', 'webapp', 'block-blockname'? Not sure it will be easy to navigate among all those 'cocoon-foo's :) Agree, M2 repositories provide hierarchial group id's: org.apache.cocoon e.g. So there is no need for globally unique artifact id's anymore. /Daniel
Re: [VOTE] green light for flattening repo structure in trunk
Vadim Gritsenko wrote: Jorg Heymans wrote: [ +1 ] flatten the structure and pave the way for a 2.2 release Minor point: does it have to be 'cocoon-core', 'cocoon-webapp', 'cocoon-blockname'; could it be 'core', 'webapp', 'block-blockname'? Not sure it will be easy to navigate among all those 'cocoon-foo's :) Matching the directory name with the artifactId is recommended practice. I can't exactly remember the benefits, but i know it saves extra configuration in reactor builds eg when using continuum. Jorg
Re: [VOTE] green light for flattening repo structure in trunk
My account is not yet created, but please accept my vote: [X] flatten the structure and pave the way for a 2.2 release [ ] no because -- Jean-Baptiste Quenot Systèmes d'Information ANYWARE TECHNOLOGIES Tel : +33 (0)5 61 00 52 90 Fax : +33 (0)5 61 00 51 46 http://www.anyware-tech.com/
Re: [vote] Jean-Baptiste Quenot as new Cocoon committer (was Re: Problem with CachingPointProcessingPipeline)
Thank you everyone! This new year is starting very nicely, and it's good to receive this sign of trust from all of you, after the hard work done lately with and within Cocoon. For those who may not have noticed, I work for a [1]french company called « Anyware Technologies » designing web-based information systems, which Sylvain Wallez co-founded a few years ago. I'm bothering him on a regular basis to ask questions about Cocoon, and to request « hacks to make it work ». Hopefully things will get better for both of us, as impatience and boredom was growing at the same rate as the [2]patch queue, until now. It's the first time for me to become a committer on an Open-Source project, however I have contributed to some pieces of OSS: Bash/Zsh completion, Resin, eXist, and especially FreeBSD (for which I maintain the Cocoon, Resin, JMeter and [3]other ports). I'm an adept of OSS since about 10 years (after being an adept of Macintosh), I also made some lectures at the [4]local LUG. Apart from business projects, I have a [5]personal home page powered by Cocoon, a Cocoon-and-AJAX-based portal (I will prepare a demo when Sylvain has the new Dojo stuff ready), and a Cocoon-based photo gallery (no demo is available yet). Good candidates for inclusion in the Cocoon samples, I will keep you in touch. I live near Toulouse France with my family since two years after spending 24 years in Paris (guess how old I am). Life in the countryside is very peaceful, however I will move to the city in february, so that I can have at last a decent Internet connection. Our hens will move as well, provided they can be satisfied by the little garden (16 times smaller!). Back to Cocoon: in the short term, I have a lot of small fixes and enhancements to offer. In the long term, let's see what we can do together (revolution or evolution) before Java/XML web applications become legacy ;-) Thanks again, -- Jean-Baptiste Quenot Systèmes d'Information ANYWARE TECHNOLOGIES Tel : +33 (0)5 61 00 52 90 Fax : +33 (0)5 61 00 51 46 http://www.anyware-tech.com/ [1] http://www.anyware-tech.com/ [2] http://issues.apache.org/jira/secure/IssueNavigator.jspa?decorator=browserview=pid=12310170reporterSelect=specificuserreporter=jbq%40anyware-tech.comsorter/field=issuekeysorter/order=DESCtempMax=25reset=true [3] http://www.freshports.org/search.php?stype=maintainermethod=matchquery=quenotnum=10orderby=categoryorderbyupdown=ascsearch=Search [4] http://www.culte.org/ [5] http://caraldi.com/jbq/
Re: [RT] The Real Component Simplification
Vadim Gritsenko wrote: URL interpretation ? SourceResolver and company It proved to be very valuable extension point I'm not negating that, however the way it is currently implemented makes it difficult to use at times. Again there are different ways of skinning this particular cat that would be more efficient. I do recall why we didn't try to use Java's own URL component framework. It really wasn't due to complexity of getting the URLStreamHandlers to communicate with Cocoon. It was due to the fact that some web containers like BEA WebLogic and IBM WebSphere preset the static instance of URLStreamHandlerFactory, making it impossible for us to override it. I don't recall if we tested extending where the URLStreamHandlers are located using the |java.protocol.handler.pkgs system property. The advantage of using Java's extension mechanism here is that we would be able to use our cocoon:// URLs inside of FOP and any other library that relies on URLs. If we don't rely on components for the core of Cocoon, then we have more flexibility on improving this point. | It is very simplistic view of the world to declare that only P/G/T deserve to be components. I'd even go as far as claim that P/G/T are implemented by cocoon users the *least* often compared to other interfaces. Well, as da Vinci said, Simplicity is the ultimate sophistication. The key point of the decomponentization process is to reduce the number of extension points to the absolute practical minimum. By being brave about what we leave out, it forces us to think differently about other aspects of the system. I'm thinking way forward here. Just don't throw out baby in the heat of fight for simplification :) Right. Although just because something is an extension point does not mean it has to necessarily be a component.
[jira] Commented: (COCOON-1709) Speedup portal loading
[ http://issues.apache.org/jira/browse/COCOON-1709?page=comments#action_12361855 ] Jean-Baptiste Quenot commented on COCOON-1709: -- You say they should be cached by Cocoon... but AFAICT there's no cache involved here as I'm not using cocoon://. But even if using cocoon:// for loading profiles, it would not take 450ms (600-150) to execute, as we're always processing them through Castor. You say you don't always see [your] updates either: does it mean that there is some caching involved? If yes, where? Is it castor? I intend to drop my patch, but I want to understand why only the first loading takes longer since you have committed your patch. Speedup portal loading -- Key: COCOON-1709 URL: http://issues.apache.org/jira/browse/COCOON-1709 Project: Cocoon Type: Improvement Components: Blocks: Portal Versions: 2.1.9-dev (current SVN) Reporter: Jean-Baptiste Quenot Attachments: 20051212-portal-MapProfileLS, 20051222-MapProfileLS.java, 20051222-MapProfileLS.java, UserRoleSourceFactory.java, portal-config Portal loads user profiles (when using eg AuthenticationProfileManager) with Castor every time the user logs in and this is very slow. This patch allows to cache the result for further invocations. However the coplet instance profiles are handled in a special way, after being obtained by mapping the CopletInstanceDataManager they are cloned to ensure that every user gets its own copy of the coplets. Thus this bug depends on http://issues.apache.org/jira/browse/COCOON-1708 Allow CopletInstanceDataManager to be cloneable. An improvement would be to store cached objects in Cocoon Store, the provided patch currently uses a simple HashMap to store profiles. Note that the key of the object is the URI returned by the source. This is important because different values of uri in resolver.resolveURI(uri) could return the same source, ie source.getURI() could be the same, so only different objects are stored in the Map. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [jira] Commented: (COCOON-1709) Speedup portal loading
* Jean-Baptiste Quenot (JIRA): Ralph, I don't know why I don't get notified of your comments, not even on cocoon-dev. Ralph, have you allowed « public comments » when posting a followup? Is it possible that one of the Jira experts can tell why Ralph's comments are not notified by email? Thanks in advance, -- Jean-Baptiste Quenot Systèmes d'Information ANYWARE TECHNOLOGIES Tel : +33 (0)5 61 00 52 90 Fax : +33 (0)5 61 00 51 46 http://www.anyware-tech.com/
Re: [vote] Jean-Baptiste Quenot as new Cocoon committer (was Re: Problem with CachingPointProcessingPipeline)
Le 5 janv. 06, à 16:34, Jean-Baptiste Quenot a écrit : ...Back to Cocoon: in the short term, I have a lot of small fixes and enhancements to offer. In the long term, let's see what we can do together (revolution or evolution) before Java/XML web applications become legacy ;-) Sounds like a plan! Thanks for your introduction and welcome! -Bertrand smime.p7s Description: S/MIME cryptographic signature
Re: [VOTE] green light for flattening repo structure in trunk
Jorg Heymans wrote:
Please cast your votes :
[X] flatten the structure and pave the way for a 2.2 release
[ ] no because
--
Reinhard Pötz Independent Consultant, Trainer (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
Re: [jira] Commented: (COCOON-1709) Speedup portal loading
When I post comments the comment viewable by setting is all users. Is there another setting you are referring to? Jean-Baptiste Quenot said: * Jean-Baptiste Quenot (JIRA): Ralph, I don't know why I don't get notified of your comments, not even on cocoon-dev. Ralph, have you allowed « public comments » when posting a followup? Is it possible that one of the Jira experts can tell why Ralph's comments are not notified by email? Thanks in advance, -- Jean-Baptiste Quenot Systèmes d'Information ANYWARE TECHNOLOGIES Tel : +33 (0)5 61 00 52 90 Fax : +33 (0)5 61 00 51 46 http://www.anyware-tech.com/
Re: [VOTE] green light for flattening repo structure in trunk
Please cast your votes : [+1 ] flatten the structure and pave the way for a 2.2 release Best Regards, Antonio Gallardo.
Re: [VOTE] green light for flattening repo structure in trunk
Jorg Heymans wrote: Vadim Gritsenko wrote: Jorg Heymans wrote: [ +1 ] flatten the structure and pave the way for a 2.2 release Minor point: does it have to be 'cocoon-core', 'cocoon-webapp', 'cocoon-blockname'; could it be 'core', 'webapp', 'block-blockname'? Not sure it will be easy to navigate among all those 'cocoon-foo's :) Matching the directory name with the artifactId is recommended practice. I can't exactly remember the benefits, but i know it saves extra configuration in reactor builds eg when using continuum. Should not be due name collision. ie: a core.jar released in another project? Yes, I will prefer to keep a prefixed name as cocoon-core.jar. No matter where we find this file, his names states it is the cocoon core. Best Regards, Antonio Gallardo.
Re: [VOTE] green light for flattening repo structure in trunk
Antonio Gallardo wrote: Jorg Heymans wrote: Vadim Gritsenko wrote: Jorg Heymans wrote: [ +1 ] flatten the structure and pave the way for a 2.2 release Minor point: does it have to be 'cocoon-core', 'cocoon-webapp', 'cocoon-blockname'; could it be 'core', 'webapp', 'block-blockname'? Not sure it will be easy to navigate among all those 'cocoon-foo's :) Matching the directory name with the artifactId is recommended practice. I can't exactly remember the benefits, but i know it saves extra configuration in reactor builds eg when using continuum. Should not be due name collision. ie: a core.jar released in another project? Yes, I will prefer to keep a prefixed name as cocoon-core.jar. No matter where we find this file, his names states it is the cocoon core. I was talking about directory name only. cocoon-core.jar is fine. Vadim
[jira] Closed: (COCOON-1709) Speedup portal loading
[ http://issues.apache.org/jira/browse/COCOON-1709?page=all ] Jean-Baptiste Quenot closed COCOON-1709: Resolution: Won't Fix Thank you Ralph, The following modification that you made in Cocoon Portal speeds up portal loading a lot, thus my patch is not needed anymore: Change from auto-naming=deriveByClass to matches attribute for performance improvement http://svn.apache.org/viewcvs?rev=360596view=rev This issue is closed. Speedup portal loading -- Key: COCOON-1709 URL: http://issues.apache.org/jira/browse/COCOON-1709 Project: Cocoon Type: Improvement Components: Blocks: Portal Versions: 2.1.9-dev (current SVN) Reporter: Jean-Baptiste Quenot Attachments: 20051212-portal-MapProfileLS, 20051222-MapProfileLS.java, 20051222-MapProfileLS.java, UserRoleSourceFactory.java, portal-config Portal loads user profiles (when using eg AuthenticationProfileManager) with Castor every time the user logs in and this is very slow. This patch allows to cache the result for further invocations. However the coplet instance profiles are handled in a special way, after being obtained by mapping the CopletInstanceDataManager they are cloned to ensure that every user gets its own copy of the coplets. Thus this bug depends on http://issues.apache.org/jira/browse/COCOON-1708 Allow CopletInstanceDataManager to be cloneable. An improvement would be to store cached objects in Cocoon Store, the provided patch currently uses a simple HashMap to store profiles. Note that the key of the object is the URI returned by the source. This is important because different values of uri in resolver.resolveURI(uri) could return the same source, ie source.getURI() could be the same, so only different objects are stored in the Map. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[VOTE] preliminary wrap-up
OK, so unless someone vetoes this the next few hours i will start shifting files about around 11pm CET today. It would be great if people could refrain from checking stuff into trunk/core from then onwards until i've finished. It will take a good few hours, i'll notify when it is done. also : should we make some sort of backup first or is everything fully reversible from the svn command line ? Just to be on the safe side ... Jorg
Re: [VOTE] preliminary wrap-up
Jorg Heymans wrote:
OK, so unless someone vetoes this the next few hours i will start
shifting files about around 11pm CET today.
It would be great if people could refrain from checking stuff into
trunk/core from then onwards until i've finished. It will take a good
few hours, i'll notify when it is done.
also : should we make some sort of backup first or is everything fully
reversible from the svn command line ? Just to be on the safe side ...
no backup is required as svn stores the complete history.
--
Reinhard Pötz Independent Consultant, Trainer (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
Re: [VOTE] preliminary wrap-up
Jorg Heymans wrote: OK, so unless someone vetoes this the next few hours i will start shifting files about around 11pm CET today. It would be great if people could refrain from checking stuff into trunk/core from then onwards until i've finished. It will take a good few hours, i'll notify when it is done. also : should we make some sort of backup first or is everything fully reversible from the svn command line ? Just to be on the safe side ... Tag the trunk before you start, and then again afterwards. But to answer your question, yes everything is reversible from the svn command line.
cvs generator update
Updates in the source: Correction: The generator now looks for the sitemap parameter process-headers (with the s at the end) as told in the documentation New feature: The generator now accepts a new sitemap parameter max-records which allows to limit the number of records to read. The default is 0 ( = read all records) Philippe CSVGenerator.java Description: CSVGenerator.java
Re: [VOTE] green light for flattening repo structure in trunk
Jorg Heymans wrote: [X] flatten the structure and pave the way for a 2.2 release Same here. Bye, Helma
Re: XTech 2006 Amsterdam, May 16-19th
Daniel Fagerstrom wrote: Stefano Mazzocchi wrote: Arje Cahn wrote: FYI, I'm on the technical review board of that conference. Will you attend too? Don't know, probably not, but I'll have to be in Sweden the week after that to given a keynote speech, so I might be able to stop by ;-) What conference are you giving your keynote speach in? Last year it was called Nordic Sofware Developer Summit 2005 - NorDev 2005, so I suspect it's going to NorDev 2006 this year. -- Stefano.
Re: [VOTE] green light for flattening repo structure in trunk
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thu, 5 Jan 2006, Antonio Gallardo wrote: Date: Thu, 05 Jan 2006 11:24:40 -0600 From: Antonio Gallardo [EMAIL PROTECTED] Reply-To: dev@cocoon.apache.org To: dev@cocoon.apache.org Subject: Re: [VOTE] green light for flattening repo structure in trunk Jorg Heymans wrote: Vadim Gritsenko wrote: Jorg Heymans wrote: [ +1 ] flatten the structure and pave the way for a 2.2 release Minor point: does it have to be 'cocoon-core', 'cocoon-webapp', 'cocoon-blockname'; could it be 'core', 'webapp', 'block-blockname'? Not sure it will be easy to navigate among all those 'cocoon-foo's :) Matching the directory name with the artifactId is recommended practice. I can't exactly remember the benefits, but i know it saves extra configuration in reactor builds eg when using continuum. Should not be due name collision. ie: a core.jar released in another project? Yes, I will prefer to keep a prefixed name as cocoon-core.jar. No matter where we find this file, his names states it is the cocoon core. There is a project/build/finalName element in the pom.xml to define the artifact name. - -- Giacomo Pati Otego AG, Switzerland - http://www.otego.com Orixo, the XML business alliance - http://www.orixo.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDvZZALNdJvZjjVZARApo1AKCvMTgUt84IB81HisOwHqS7AC/6NgCcCYeo qv1TSElVNyj5W9EbMBZVtpc= =khdX -END PGP SIGNATURE-
Re: [VOTE] preliminary wrap-up
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thu, 5 Jan 2006, Jorg Heymans wrote: Date: Thu, 05 Jan 2006 19:14:19 +0100 From: Jorg Heymans [EMAIL PROTECTED] Reply-To: dev@cocoon.apache.org To: dev@cocoon.apache.org Subject: [VOTE] preliminary wrap-up OK, so unless someone vetoes this the next few hours i will start shifting files about around 11pm CET today. It would be great if people could refrain from checking stuff into trunk/core from then onwards until i've finished. It will take a good few hours, i'll notify when it is done. also : should we make some sort of backup first or is everything fully reversible from the svn command line ? Just to be on the safe side ... As long as you've always used the svn command to move things around it should be revertable (even without a network connection). - -- Giacomo Pati Otego AG, Switzerland - http://www.otego.com Orixo, the XML business alliance - http://www.orixo.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDvZaxLNdJvZjjVZARAhFuAKC2u/FyMyJCRtyEsqjZ+KG5JEAHmACdEJFt eQYGcMALTo1gXQgbCLxSqiI= =9dny -END PGP SIGNATURE-
Re: [VOTE] flattening process started
(i tagged trunk beforehand as suggested) Jorg
Re: I'm lost...could we have more README files?
Bertrand Delacretaz wrote: Would it be possible for people working in these areas to create short README files in the trunk, and keep them up to date when something happens in that area? There's already README.osgi, we could have README.maven, README.jmx, README.blockmode, etc.. Please use the .txt extension. Otherwise we will get more svn properties problems than we already have. We get conflicting line-endings and un-necessary diffs. My goal is to allow any of us to experiment with these new features even if they haven't followed them closely, by finding the necessary information, links, status etc. in one place. So, I'd be thankful if people who work in these areas could keep us up to date in this way, so that we can share the excitment about these new features. I know this ultimately belongs to some docs, but as these things are still evolving it's much easier to keep a single file up to date per feature/mode. If docs are here already, just put an link to them in the README file. However all docs are still evolving. Wouldn't it be better in Daisy where all can see. Anyway whatever, any docs are good. -David
Re: [VOTE] green light for flattening repo structure in trunk
Jorg Heymans wrote: Please cast your votes : [ +1 ] flatten the structure and pave the way for a 2.2 release [ ] no because -David
Re: [RT] The Real Component Simplification
Carsten Ziegeler wrote: Daniel Fagerstrom wrote: Decomponentization could start right away. Do you have any concrete examples of components that shouldn't be components? The XMLSerializer/XMLDeserializer combo is one of the best examples, I think. These shouldn't be components. If noone objects I'll do the changes for 2.2 - we already discussed this years ago :) I never wrote avalon components for my cocoon needs. :-) Hence, any step to a simpler architecture deserves a big +1! Best Regards, Antonio Gallardo. Carsten
[M10N] end of first flattening round
Moved following blocks : - core - mocks - session-fw - authentication-fw they are all located in /trunk now. you should get : [INFO] Apache Cocoon .. SUCCESS [2.582s] [INFO] Cocoon Core SUCCESS [41.436s] [INFO] Core Mocks . SUCCESS [0.696s] [INFO] Session Framework .. SUCCESS [0.091s] [INFO] Session Framework Implementation ... SUCCESS [2.732s] [INFO] Session Framework Sample Application ... SUCCESS [0.519s] [INFO] Authentication Framework ... SUCCESS [0.067s] [INFO] Authentication Framework Implementation SUCCESS [3.651s] [INFO] Authentication Framework Sample Application SUCCESS [0.489s] [INFO] BUILD SUCCESSFUL Notes == - tests are currently not compiling because of corrupt HtmlUnit poms, so always run with -Dmaven.test.skip=true. - the block structure is maven compliant already but probably does not resemble our true block structure quite yet. This is easy to do so once we nail down the block layout together with the deployer. For now i've put the WEB-INF/xconfs in resources. - the java directories still have non-java files in them. Someone should still do something like find . -name 'all-files-not-ending-in-java' | xargs svn delete on the java directories - i applied the naming convention of the maven repo, we can argue about this later for now it'll do. - things are still pretty rough overall, expect improvements soon especially wrt eclipse plugin integration. - we should use this minimal setup of core + 2 basic interdependent blocks to get the deployer going and formalize the block structure before we start adding more complicated blocks. - if people want something easy to help out, start looking at the assembly format for binary releases. We'll need it quite soon. Also the Htmlunit pom needs to be added to cvs.apache.org (alternatively log this in maven jira under maven evangelism or ping the htmlunit authors directly) That's all for now, 'night folks Jorg
Re: I'm lost...could we have more README files?
David Crossley wrote: Bertrand Delacretaz wrote: Would it be possible for people working in these areas to create short README files in the trunk, and keep them up to date when something happens in that area? There's already README.osgi, we could have README.maven, README.jmx, README.blockmode, etc.. Please use the .txt extension. Otherwise we will get more svn properties problems than we already have. We get conflicting line-endings and un-necessary diffs. +1. Adding new extensions is not a good idea. Perhaps a solution can be: README.maven.txt README.osgi.txt etc. It can be done with: svn mv REAME.maven README.maven.txt Best Regards, Antonio Gallardo.
Re: [VOTE] green light for flattening repo structure in trunk
[+1] flatten the structure and pave the way for a 2.2 release cheers -- Torsten PGP.sig Description: This is a digitally signed message part
Re: [VOTE] preliminary wrap-up
On Friday 06 January 2006 02:26, Berin Loritsch wrote: Tag the trunk before you start, and then again afterwards. Tag == copy == backup, so it may sound a bit contradictory to Jorg. And although copy in SVN is very cheap, I am finding this CVS practice less important, since all commits are atomic and good commit messages can be reviewed and identifying when things happen. But maybe just me. Cheers Niclas
Re: [VOTE] preliminary wrap-up
Niclas Hedhman wrote: On Friday 06 January 2006 02:26, Berin Loritsch wrote: Tag the trunk before you start, and then again afterwards. Tag == copy == backup, so it may sound a bit contradictory to Jorg. And although copy in SVN is very cheap, I am finding this CVS practice less important, since all commits are atomic and good commit messages can be reviewed and identifying when things happen. But maybe just me. +1 a revision number is enough. Best Regards, Antonio Gallardo.
